Did you try to revert it? Patch itself has no functional changes, it just replaces bunch of similar condition checks and puts it in one place.

I maked bisect, but may do it twice.

Oh, excuse me Nikolay, real regression in(looks like i used one version twice):
c6f6c3f727556734905a5bbf4fe1b59079e37bf5 is the first bad commit
commit c6f6c3f727556734905a5bbf4fe1b59079e37bf5
Author: Huw Davies <huw@codeweavers.com>
Date:   Fri Aug 19 16:26:19 2011 +0100

    gdi32: Implement Polyline and PolyPolyline in the dib driver.

:040000 040000 33b178ecafaa1bd7848008ca024ec7da25ebdd25 2b1394ab249ef06c775d11b35e9c2d31e1fc9b19 M	dlls

I confirm the regression, and my bisection also points to commit c6f6c3f727556734905a5bbf4fe1b59079e37bf5 by Huw Davies.

When I reverse-apply that patch over wine-1.3.31 and rebuild, the problem no longer persists.

Confirming as per comment 4.

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.)

OK, some more accurate statistics.

On my machine, on a fresh start, 2gis draws about 20000 lines, each on average being 16px long (for a total of 322000 pixels). This takes 135 seconds (measured by adding up the differences of GetTickCount() at start and end of bres_line_with_bias). Dividing, we get average speed of 2380 pixels per second on this Core2 Duo E6850 @ 3GHz, which doesn’t exactly strike me as reasonable line drawing performance.

Next I’m going to dump this as MoveTo/LineTo calls and compare the performance on Windows vs Wine.

Also, I tried to restructure the algorithm to reduce the number of calls to solid_rects, by consolidating sequential pixels with the same Y coordinate into a single rect, and this didn’t have any effect on the performance.

(In reply to comment #7)

> Also, I tried to restructure the algorithm to reduce the number of calls to
> solid_rects, by consolidating sequential pixels with the same Y coordinate into
> a single rect, and this didn’t have any effect on the performance.

I plan on moving the Bresenham algorithm down to the primitives, which should help a lot.

Created attachment 37522 [details]
Care to see if this patch helps?

Sadly, no noticeable effect on productivity. Rendering the same map extent (266K pixels, 16658 lines) twice on program startup seems to take 105 s in bres_line_with_bias on 1.3.33, 106s in solid_line_32 on 1.3.33 with patch. Measuring with a stopwatch, I get 3 minutes since I click the Next button on the startup screen until the CPU meter drops to near zero.

Maybe my measurements are not quite sound because of timer accuracy. Here’s how I do it. At the top of function to profile, I add this:

static DWORD time_total = 0, length_total = 0;
DWORD time_once = GetTickCount(), length_once = /*suitable code*/;

At the end:

time_once = GetTickCount() - time_once;
time_total += time_once;
length_total += length_once;
TRACE_(dib_profile)("Spent %d ms for %d px, total %d ms for %d px\n",
    time_once, length_once, time_total, length_total);

and run with WINEDEBUG=+dib_profile, redirecting all output to a file. The resulting file has many lines with spent time = 0 ms and some lines where spent time is about 45 ms. I assume it all statistically adds up to roughly the correct total in the end.

I suspect the slow (45ms) cases are because the dib driver has previously forwarded a graphics operation to the winex11 (because it doesn't yet handle that op), so before it can draw the line it needs to copy the bits back from the X11 side.  It would be interesting to know which operation is being forwarded.  Could you produce a +relay,+tid,+seh,+bitmap,+dib,+x11drv log ?

(In reply to comment #11)

> Could you produce a +relay,+tid,+seh,+bitmap,+dib,+x11drv log ?

A log this detailed shows a lot of things happen and is too big to attach here. I have trimmed the log to trace the lifetime of a single DC into which the polylines are drawn: http://wine.centaur.ath.cx/grym.20111121.fragment.log.gz (9.2M, 278'663'397 bytes uncompressed). If needed, the original untrimmed log is at http://wine.centaur.ath.cx/grym.20111121.orig.log.gz (19M, 543'355'952 bytes uncompressed).

Thanks for the log.

The problem is the PolyPolygon calls that interleave the Polyline()s.  These are currently not handled by the dib driver to so forwarded to winex11.drv, which means the dib bits are copied back and fore between the client and the XServer.

The polygon stuff should happen reasonably soon.

Nice to know. Thank you for taking the time to investigate this.

So, before the implementation of polylines, all work happened on the X11 server side, and after polygons all work will be done on the application side, but for now they polylines are drawn app-side and polygons server-side, causing lots of roundtrips.

And, I can immediately imagine a reason why polylines might be interleaved with polygons: Railroads are drawn as strings of almost rectangular sections, one solid, one hollow, repeating for the whole length of the railroad.

As a stopgap measure, I build packages for Ubuntu without the offending commit and publish them at https://launchpad.net/~yurivkhan/+archive/ubuntu-wine .

*** Bug 29258 has been marked as a duplicate of this bug. ***

looks like 2gis runs normal(or near that) on 1.3.36

I confirm — with 1.3.36, the problem no longer seems to persist on my machine.

Reported fixed.

Closing bugs fixed in 1.3.37.