[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(a)winehq.org Reporter: gustep12(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor --- Comment #1 from Rosanne DiMesio <dimesio(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW URL| |https://stanford.box.com/s/ | |69ijfwjf7qc95bq6bh2m CC| |gyebro69(a)gmail.com, | |julliard(a)winehq.org Ever confirmed|0 |1 Regression SHA1| |33ac850c80634c891b0c157bbff | |a612f70954a40 --- Comment #2 from Béla Gyebrószki <gyebro69(a)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(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Béla Gyebrószki <gyebro69(a)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 | -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|33ac850c80634c891b0c157bbff | |a612f70954a40 | --- Comment #3 from Alexandre Julliard <julliard(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression |performance Status|NEW |RESOLVED Component|gdi32 |winex11.drv Resolution|--- |WONTFIX --- Comment #4 from Ken Sharp <imwellcushtymelike(a)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). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 --- Comment #5 from Sebastian <gustep12(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 --- Comment #7 from Alexandre Julliard <julliard(a)winehq.org> --- This may be improved now, please retest with 1.8-rc2. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 --- Comment #8 from Sebastian <gustep12(a)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.
https://bugs.winehq.org/show_bug.cgi?id=37308 --- Comment #9 from Sebastian <gustep12(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED Resolution|WONTFIX |FIXED --- Comment #10 from Alexandre Julliard <julliard(a)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! -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 --- Comment #11 from Austin English <austinenglish(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=37308 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.8-rc3. -- 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.
participants (1)
-
wine-bugs＠winehq.org