http://bugs.winehq.org/show_bug.cgi?id=28604
--- Comment #6 from Yuri Khan yurivkhan@gmail.com 2011-11-12 09:57:49 CST --- I have investigated the issue further and here’s what I found.
I added trace output to dibdrv_Polyline, logging the number of points and the time it took to draw. I get values like 45ms per polyline; the most popular point count is 5 (suggesting a quadrangle).
The time is mostly spent actually drawing lines, in calls to solid_pen_lines which calls solid_pen_line which handles clipping to the current region and calls bres_line_with_bias which implements the Bresenham line drawing algorithm and for each pixel calls the callback function solid_pen_line_callback which calls solid_rects for a single-pixel rectangle. (Which looks like a lot of function-call overhead which also cannot be optimized out by inlining because of the callback.)
I also tried bypassing the whole function, by adding a “return TRUE;” at the top. The slowdown no longer reproduced, and the only part of functionality that suffered was the railroads — the white sections were not painted.
So it seems to me that the alternative way (which, if I understand correctly, involves round-tripping to the X server) is faster than Wine’s Bresenham. (This also explains the similar slowness when running 2gis over ssh with X forwarding. When the X server is on the local machine (including ssh -Y localhost), round-tripping is fast; on another machine on the same 100Mbit switch it is slow.)