[Bug 37308] PCB123 v2.1.0.7000: slow screen redrawing

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=37308

--- Comment #8 from Sebastian <gustep12 at yahoo.com> ---
Yes, it works! Thank you!

I just tested this program with Wine 1.8-rc2 32bit and I can confirm that it is
a significant improvement. The rendering is now incremental and therefore
appears more responsive than before, where only the final result used showed up
on the screen. I definitely much prefer this incremental display, which is
closer to how I remember the program originally.

Added bonus: This fix to Wine 1.8-rc2 works well under PlayOnlinux. The
previous work-around, ClientSideGraphics=N, only worked with Wine directly, but
didn't make any difference when applied via PlayOnLinux.

The fix in 1.8-rc2 was to reduce the idle timeout before a buffer flush would
be forced from 1000ms to 50ms. Would it be possible to reduce this even further
to maybe 5ms for testing, for example by making this a configurable parameter?
This might help if there are some programs which don't flush the buffer but
instead wait for a flush to occur by external means before they continue.

*****

By the way, I found and interesting document relating to GDI performance:
http://www.opennetcf.com/ctacke/archives/GDI_Performance.pdf

The conclusion there was that managed code can be much slower than native C /
C++ code for making GDI calls, but that the performance of managed code can be
recovered when P/Invoke is used instead of the regular managed call. Not
relevant to this fix or Wine, but maybe useful for anyone interested in
performance-tuning GDI in general.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.