[Bug 37308] New: GDI performance regression after Ubuntu 12.04 to 14.04 upgrade; incl. testable app
https://bugs.winehq.org/show_bug.cgi?id=37308
Bug ID: 37308 Summary: GDI performance regression after Ubuntu 12.04 to 14.04 upgrade; incl. testable app Product: Wine Version: 1.6.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: gdi32 Assignee: wine-bugs@winehq.org Reporter: gustep12@yahoo.com
Thank you for working on Wine. I love the fact that Wine occasionally works better (much faster and yet accurate rendering) for legacy Windows XP applications than newer Windows versions!
For example, here is a legacy CAD application which is easy to install and run in Wine, but which is very GDI intensive. As such, it is a good test for GDI speed issues. When you open a complex CAD file, this app runs nicely in Windows XP, but 5x or 10x slower in Windows Vista and later. Fortunately, it runs at least the same or faster in Wine than it does in WinXP!
In fact, I guess I run this app half the time just to see how and if Wine is working.
The application in question is PCB123 v2.1.0.7000, you can search for it online or get the 7MB installer here. It always installs easily and works well in Wine:
pcb123installer.exe (v2.1.0.7000, ~7MB): https://stanford.box.com/s/69ijfwjf7qc95bq6bh2m
I purposely use this older version of PCB123 because, compared to versions that came later, it has significantly faster display rendering performance with complex PCB designs, such as this one, which I made:
PCB123-v2-complex-testfile.123, ~800kB: https://stanford.box.com/s/3kmfcif91c1e909ak7jc
If you open this *.123 PCB design file and turn the mousewheel to zoom in or out, it triggers a complete screen redraw. A screen redraw can take from one to five seconds on sub-optimal software (Windows Vista/7/8, newest Wine), but should take only a fraction of a second with good software (Windows XP, earlier Wine).
If the scree re-draw takes too long, you can hide the filled copper planes of the PCB. This speeds up redraws significantly, but the general issue (rendering is now slower than it used to be, decreasing productivity) remains:
PCB123-v2-complex-testfile-nofill.123, ~800kB: https://stanford.box.com/s/08zamniq0gx3imlwhi76
This software was originally released in the Windows XP years. It ran much worse on Windows 7. It ran super-fast on Wine, regardless of hardware and/or Linux version, I believe. Over time, I ran this software under Wine on a few different Linux distros (Fedora, Mint, Ubuntu), and different hardware (older Thinkpad with slow IGP, newer desktop with GTX660), the results were always great under Linux+Wine, and much poorer under Windows 7.
Most recently, I had it running smoothly on Ubuntu 12.04 LTS, probably with Nvidia binary driver 319 and whatever Wine version was up to date.
Then, about three days ago, I let Ubuntu proceed with the upgrade to 14.04 LTS. Initially, PCB123 worked quickly, but then another set of Ubuntu 14.04 updates came in, probably including the Nvidia driver update v331. Somehow this un-installed Wine, and I couldn't re-install it - same issue as described here:
http://askubuntu.com/questions/449507/nvidia-libopencl1-331-has-to-be-remove...
Following the instructions on that page, I then did this:
sudo apt-get install nvidia-cuda-toolkit #Need to get 250 MB of archives; 774 MB of additional disk space will be used
sudo apt-get install ocl-icd-opencl-dev #this will remove nvidia-libopencl1-* and nvidia-opencl-dev
sudo apt-get install wine #Need to get 121 MB; 342 MB of additional disk space will be used.
Then I reinstalled Wine successfully, but then somehow the display performance of PCB123 got much, much slower. I estimate the screen redraw speed is now at least 20x to 50x slower than it used to be.
I am now trying to roll back the Nvidia drivers, the Wine versions, and so forth, to narrow down where the problem lies. No luck so far, PCB123 remains slow. I may even try to install Ubuntu 12.04 LTS again just to see if this fixes it. Any advice on how I can force different versions of Wine or relevant DLLs for testing?
Any tips on how I can support fixing this issue?
Best regards, Sebastian
https://bugs.winehq.org/show_bug.cgi?id=37308
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor
--- Comment #1 from Rosanne DiMesio dimesio@earthlink.net --- Not major. https://bugs.winehq.org/page.cgi?id=fields.html
I can confirm that in 1.7.27, screen redraw on the sample file takes 1-5 seconds when zooming in or out with the mousewheel. Tested on Nvidia GT 630, 331.38 driver. Whether that's a regression, I don't know. If the performance on your system is slower than that, I suspect it is related to your problems with the Nvidia driver package.
Bugzilla is not for user support; ask for help with your driver issues on the Ubuntu forum. If you really believe this is a regression in Wine, please run a regression test. http://wiki.winehq.org/RegressionTesting
https://bugs.winehq.org/show_bug.cgi?id=37308
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
https://bugs.winehq.org/show_bug.cgi?id=37308
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW URL| |https://stanford.box.com/s/ | |69ijfwjf7qc95bq6bh2m CC| |gyebro69@gmail.com, | |julliard@winehq.org Ever confirmed|0 |1 Regression SHA1| |33ac850c80634c891b0c157bbff | |a612f70954a40
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- I can reproduce the problem in wine-1.7.43-166-g39d71c5
Setting the registry key 'ClientSideGraphics=N' under HKCU\Software\Wine\X11 Driver works around the problem for me and zooming in/out with the mousewheel is smooth again. (http://wiki.winehq.org/UsefulRegistryKeys)
The result of the regression test:
33ac850c80634c891b0c157bbffa612f70954a40 is the first bad commit commit 33ac850c80634c891b0c157bbffa612f70954a40 Author: Alexandre Julliard julliard@winehq.org Date: Thu Sep 6 12:39:34 2012 +0200
winex11: Use window surfaces for rendering top-level windows.
It can be disabled by setting "ClientSideGraphics"="n".
See also bug #35418.
Fedora 21 XOrg 1.16.3 XFCE 4.10 Nvidia binary drivers 340.76
https://bugs.winehq.org/show_bug.cgi?id=37308
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|GDI performance regression |PCB123 v2.1.0.7000: slow |after Ubuntu 12.04 to 14.04 |screen redrawing |upgrade; incl. testable app |
https://bugs.winehq.org/show_bug.cgi?id=37308
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|33ac850c80634c891b0c157bbff | |a612f70954a40 |
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- Technically not a regression, that code path has always been slow.
It could probably be improved, though if the performance is really the same as on modern Windows, there probably isn't a whole lot we can do.
https://bugs.winehq.org/show_bug.cgi?id=37308
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression |performance Status|NEW |RESOLVED Component|gdi32 |winex11.drv Resolution|--- |WONTFIX
--- Comment #4 from Ken Sharp imwellcushtymelike@gmail.com --- (In reply to Sebastian from comment #0)
This software was originally released in the Windows XP years. It ran much worse on Windows 7.
(In reply to Alexandre Julliard from comment #3)
It could probably be improved, though if the performance is really the same as on modern Windows, there probably isn't a whole lot we can do.
WONTFIX. Can be reopened if someone thinks that they can improve things here (or can find a bug).
https://bugs.winehq.org/show_bug.cgi?id=37308
--- Comment #5 from Sebastian gustep12@yahoo.com --- I can confirm that with the registry setting ClientSideGraphics=N it works really well again. Thank you, thank you!!
Basically with that setting, the program is just as fast (or faster), and renders incrementally on the screen, just as it used to be under Windows XP.
With ClientSideGraphics=Y, Wine is probably duplicating the slow off-screen rendering performance that this program also experiences under Windows 7 and up.
My recommendation would be to make ClientSideGraphics=N the default as long as "Windows Version = Windows XP" is selected in the Wine Configuration. Is there any downside to this setting?
https://bugs.winehq.org/show_bug.cgi?id=37308
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=37308
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- This may be improved now, please retest with 1.8-rc2.
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.
https://bugs.winehq.org/show_bug.cgi?id=37308
--- Comment #9 from Sebastian gustep12@yahoo.com --- I also just compared the following:
Wine 1.8-rc2 32bit with PCB123.exe and drawing PCB123-v2-complex-testfile-nofill.123
ClientSideGraphics=Y Result: 1.8-rc2 gives much improved appearance and response due to more regular buffer flushes. However, it still appears a little slower. When continuously zooming with the mousewheel, some elements are occasionally missing for a short moment - maybe for 50ms - 200ms at a time?
ClientSideGraphics=N Result: Still the fastest response. When continuously zooming with the mousewheel, the response is fast, and the entire drawing is stable (no elements are lagging).
I think both options are o.k., but please preserve the option to set ClientSideGraphics=N for special cases.
https://bugs.winehq.org/show_bug.cgi?id=37308
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED Resolution|WONTFIX |FIXED
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- (In reply to Sebastian from comment #8)
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.
The flush should be transparent to the application, there's no mechanism for it to wait for a flush.
For now you can tweak the timeout in the source, I don't expect it to make a lot of difference, but by all means please give it a try and let me know.
Marking bug fixed, thanks for testing!
https://bugs.winehq.org/show_bug.cgi?id=37308
--- Comment #11 from Austin English austinenglish@gmail.com --- (In reply to Alexandre Julliard from comment #10)
For now you can tweak the timeout in the source, I don't expect it to make a lot of difference, but by all means please give it a try and let me know.
Perhaps it should be adjustable via the registry?
https://bugs.winehq.org/show_bug.cgi?id=37308
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.8-rc3.
-
wine-bugs＠winehq.org