https://bugs.winehq.org/show_bug.cgi?id=37308
--- Comment #8 from Sebastian gustep12@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.