[Bug 35418] New: some drawing operations in Mixcraft 6 are very slow with client-side graphics enabled
http://bugs.winehq.org/show_bug.cgi?id=35418 Bug ID: 35418 Summary: some drawing operations in Mixcraft 6 are very slow with client-side graphics enabled Product: Wine Version: 1.7.11 Hardware: x86 URL: http://acoustica.com/mixcraft/download.htm OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: s_chriscollins(a)hotmail.com Classification: Unclassified Regression SHA1: 33ac850c80634c891b0c157bbffa612f70954a40 According to my git bisect, this bug appeared after the following commit: -------- winex11: Use window surfaces for rendering top-level windows. It can be disabled by setting "ClientSideGraphics"="n". commit: 33ac850c80634c891b0c157bbffa612f70954a40 -------- After the above commit, the following operations in Mixcraft 6 are very slow/laggy: 1) Scrolling vertically in the track view when there are lots of tracks present 2) Scrolling horizontally in piano roll view. 3) Resizing the workspace between the top and bottom view. 4) Adjusting the knobs and sliders of certain FX plugins. Steps to Reproduce: 1) Download and setup the Mixcraft trial (http://acoustica.com/mixcraft/download.htm). 2) If you are opening Mixcraft for the first time, it will auto-load and play a demo project. After this happens, click the "Open Project" icon (looks like a folder), and open "Callisteia.mx6". If it isn't showing in the file picker by default, you can find it in: "C:\Program Files\Acoustica Mixcraft 6\Example Projects". Go to step 4. 3) If you are opening Mixcraft after having already opened it before, it will start instead with a "New Project" dialog. Simply click the "Browse..." button here to find and open the file mentioned in step 2. 4) With "Callisteia.mx6" now opened, use the scrollbar to the right to scroll up and down through all the tracks in the project. 5) Double-click on the instrument clip for track #8 (Sweet Flute). This will bring up the clip in notation view at the bottom half of the screen. Near the bottom-left, change Editor Type from "Notation" to "Piano Roll". Use the scrollbar to scroll right and left in the piano roll view. 6) Position your cursor just below the playback controls near the middle of the screen; it should turn into a resize handle. Hold down the mouse button and move the mouse up and down to resize the split between the top and bottom screen areas. Result: The tests done in steps 4-6 are responsive and reasonably smooth in Wine versions prior to the aforementioned commit. In versions after the commit, these tests give very choppy and laggy results. I had mentioned that some FX plugins were also choppy/laggy, but this only affects some of the plugins that are bundled with Mixcraft Pro Studio 6, which is not available as a free trial download. Just in case anybody wants to know, the plugins are: FAT+, Ferox Tape Emulator, all "Mid-Side" plugins, TB Gate, and TimeMachine. If you want to test a free plugin that exhibits the slowness, and you know how to bring up a VST's GUI within Mixcraft, you can download L3V3LL3R: http://www.platinumears.com/l3v3ll3r.html. Be sure to copy the .dll file to "C:\Program Files\VST". -- 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.
http://bugs.winehq.org/show_bug.cgi?id=35418 S. Christian Collins <s_chriscollins(a)hotmail.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.
http://bugs.winehq.org/show_bug.cgi?id=35418 --- Comment #1 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- I forgot to mention: setting "ClientSideGraphics" to "N" in the registry works around the 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=35418 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|33ac850c80634c891b0c157bbff | |a612f70954a40 | --- Comment #2 from Alexandre Julliard <julliard(a)winehq.org> --- Technically not a regression, just a DIB engine performance issue. -- 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=35418 S. Christian Collins <s_chriscollins(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.11 |1.7.25 -- 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=35418 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | --- Comment #3 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Please try again in Wine 1.7.48. -- 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=35418 Sebastian <gustep12(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gustep12(a)yahoo.com --- Comment #4 from Sebastian <gustep12(a)yahoo.com> --- (In reply to Ken Sharp from comment #3)
Please try again in Wine 1.7.48.
O.k. I am in the process of downloading Wine x86 1.7.48, 1.7.48 staging, 1.7.49, 1.7.49 staging, as well as Wine amd64 1.7.48 and 1.7.49. I am trying to use PlayOnLinux to manage the Wine versions. Which of these versions should I try? My original Wine install came with Linux Mint 17.2, it was Wine 1.6.2, I believe. Also, can you mention what was changed? Did you make ClientSideGraphics=N the default setting, or is there another change? Thank you! -- 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=35418 --- Comment #5 from Sebastian <gustep12(a)yahoo.com> --- By the way, how can I add other programs that are affected by this issue? I noticed this issue with PCB123v2, where it makes a very noticeable difference in rendering performance. I suspect many more legacy programs could be affected. -- 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=35418 --- Comment #6 from Sebastian <gustep12(a)yahoo.com> --- O.k., I did some more testing: ClientSideGraphics=N is the only solution that works well (tested on both Wine 1.6.4 and 1.7.44). However, ClientSideGraphics=N only takes effect if the program is started from the system file explorer (Nemo). If I try to start the program from PlayOnLinux, then it always behaves like ClientSideGraphics=N, no matter what Wine version I configure inside PlayOnLinux, and regardless of how I configure this key in the registry. Maybe I haven't discovered how to edit the registry for PlayOnLinux properly? Different users, maybe? I also don't know how to try install Wine 1.7.48 for the system, other than through PlayOnLinux: sudo apt-get install wine1.7<br> wine1.7 is already the newest version. sudo apt-get install wine1.7.48<br> E: Unable to locate package wine1.7.48 Sorry... I'll probably figure it out shortly, but advice is appreciated. -- 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=35418 --- Comment #7 from Sebastian <gustep12(a)yahoo.com> --- Correction: I meant to write, if I start the program from PlayOnLinux, rendering is always performing poorly, as if ClientSideGraphics=Y is permanently set, despite my edits of the registry. This applies to all Wine versions which I tested in PlayOnLinux, Wine v. 1.6.4, 1.7.44, 1.7.48, 1.7.49 If I start Wine from the system (as opposed through PlayOnLinux), then the regedit seems to work, meaning ClientSideGraphics=N results in good rendering performance, but ClientSideGraphics=Y results in poor rendering performance. I could test this with Wine 1.6.4 and 1.7.44. I could not test this with 1.7.48 since I haven't yet figured out how to install v1.7.48 to the system, without using PlayOnLinux. -- 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=35418 --- Comment #8 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- I just tested with Wine 1.7.49 and Mixcraft with client-side graphics enabled is still slow and laggy. -- 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=35418 --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> --- I don't see a noticeable slowdown in the operations mentioned. Are there other places where it's more obvious? -- 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=35418 --- Comment #10 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- Not sure... here is a video I made showing the issue on my system: https://youtu.be/fSFYyz9BVPU I am using Mixcraft 7 in this video, but I remember the issue occurring with Mixcraft 6 as well (not installed currently). This happens under Wine 1.7.52 on both of my systems, specs listed below: ** My Desktop ** OS: Kubuntu 14.04 64-bit w/ KDE SC 4.14.13 Motherboard: ASRock X58 Extreme3 (Intel X58 chipset) CPU: Intel Core i7 930 (2.8 GHz quad-core) RAM: 12GB DDR3 Video: NVIDIA GeForce 7900 GS w/ 256 MB RAM (PCI Express) Linux Kernel: 3.13.0-68-lowlatency NVIDIA video driver: 304.131 Screen #1 Resolution: 1280 x 960 @ 100 Hz Screen #2 Resolution: 1280 x 1024 @ 75 Hz ** My Laptop ** OS: Kubuntu 14.04 64-bit w/ KDE SC 4.14.13 PC: HP Pavilion m6-1035dx CPU/GPU: AMD A10-4600M APU with Radeon HD 7660G Graphics RAM: 6GB DDR3 800 MHz Linux Kernel: 3.16.0-53-generic Screen Resolution: 1366 x 768 -- 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=35418 --- Comment #11 from Sebastian <gustep12(a)yahoo.com> --- O.k., I just watched the youtube video. I have seen similar issues with other applications, and I would also like to see this bug get more attention. The difference in performance is pretty significant and the fix seems easy, but yet this isn't being done. Alexandre, could you or someone else maybe explain technically under what circumstances the ClientSideGraphics=Y option could degrade the rendering performance? Apparently this was not anticipated when ClientSideGraphics were first implemented in WINE. With some hints, maybe I can write a graphical test app (fps benchmark) to isolate the problem. And furthermore, why not simply turn ClientSideGraphics off all the time? Are there any clearly measurable benefits to having it turned on? Could it be that ClientSideGraphics=Y causes more problems than it solves... ? The pros and cons of this option are not clear to me, sorry. My question for Christian Collins is: What OS version was Mixcraft originally designed to run on? And what issues are you encountering if you try to run Mixcraft on Windows 7 or Windows 10? -- 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=35418 --- Comment #12 from Sebastian <gustep12(a)yahoo.com> --- By the way, a lingering suspicion of mine is that ClientSideGraphics=Y reduces the number of screen redraws or the screen update rate. For example, maybe with ClientSideGraphics=N, every increment of the scroll bar immediately triggers a new screen update, possibly interrupting the previous screen update if it wasn't complete yet. Hence it looks smooth and responsive. Possibility 1: With ClientSideGraphics=Y, every increment of the scroll bar triggers an update in the backside rendering buffer, but the buffer isn't being flushed to the screen frequently enough to give a smooth appearance. Hence the jerky outcome. Possibility 2: Another possibility is that with ClientSideGraphics=Y, it is no longer possible to abort a slow screen rendering and start a new one, so one always has to wait for the screen rendering to be complete. Hence the jerky appearance of ClientSideGraphics=Y. Possibility 3: A third possibility is that ClientSideGraphics=N is simply a faster rendering path, so it can look smooth, whereas ClientSideGraphics=Y is so slow that the rendering can't keep up with the user input... or something like that. -- 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=35418 --- Comment #13 from Alexandre Julliard <julliard(a)winehq.org> --- It's pretty much possibiliy 1. The drawings accumulate in the buffer and are flushed once the app goes idle. This gives faster performance in most cases by suppressing redundant updates. The problem with things like dragging the scrollbar is that it never truly goes idle. We have heuristics for catching these cases and forcing updates, but they may need some tweaking. -- 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=35418 --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> --- Created attachment 52878 --> https://bugs.winehq.org/attachment.cgi?id=52878 Force idle state For instance you could try something like this. -- 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=35418 --- Comment #15 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- To answer the question about Mixcraft's intended OS, it runs on everything from XP upward, and I am unaware of any graphical issues or sluggishness under Windows 7 (which I also run), 8 or 10. Also, I am a virtual instrument designer for Acoustica, so if you have any questions for the software developers that might help narrow this bug down, I can get answers. -- 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=35418 --- Comment #16 from Sebastian <gustep12(a)yahoo.com> --- MAJOR UPDATE: I finally got the GDI benchmark working under Wine. In 2010, Tom's Hardware made a freely distributable GDI 2D benchmark and wrote an article about the decline in 2D performance as the industry was focusing on 3D benchmarks only. Unfortunately, the Tom2D benchmark isn't available anymore on the original site, but I have used it extensively in the past to investigate rendering performance declines between Windows XP and Windows 7. So I have a backup which I am making available here: Download Tom2D Benchmark 1.0 https://stanford.box.com/s/pzar5iw1kbsme4m9pbifjhmq0v1l5yct I find that it runs ok in Wine 1.6.2, and the results are very, very interesting: Ubuntu 14.04.2 Nvidia Geforce GTX 660, using x.org nouveau drivers For convenience, I am running Wine in a virtual desktop of 1024*768 With ClientSideGraphics=Y or not defined, I get: Score with "Direct Drawing to Visible Device": 4329 (all elements show) Score with "DIB Buffering": 1306 (most elements missing) With ClientSideGraphics=N, I get: Score with "Direct Drawing to Visible Device": 1584 (most elements missing) Score with "DIB Buffering": 1311 (most elements missing) So in conclusion: Not only is the rendering performance almost 3x slower, but more importantly, it only looks correct with ClientSideGraphics=N and "Direct Drawing to Visible Device". In all other cases, the drawing screen remains grey instead of showing rapidly changing colorful shapes. With DIB buffering or with ClientSideGraphics=Y, the colorful shapes show up only very occasionally and momentarily at the end of each test (text, rect, ellipse, etc.) For reference, on the same system, but running Windows, the Tom2D scores are: WinXP - Direct Draw - Cleartype Off = ~5000 WinXP - Direct Draw - Cleartype On = ~2200 -- 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=35418 --- Comment #17 from Sebastian <gustep12(a)yahoo.com> --- Sorry, I accidentally switched the results. Is there a way to edit my comment? I meant to say: With ClientSideGraphics=Y or not defined, I get: Score with "Direct Drawing to Visible Device": 1584 (most elements missing) Score with "DIB Buffering": 1311 (most elements missing) With ClientSideGraphics=N, I get: Score with "Direct Drawing to Visible Device": 4329 (all elements show) Score with "DIB Buffering": 1306 (most elements missing) ClientSideGraphics=N and "Direct Drawing to Visible Device" is the only mode which renders correctly with the Tom2D benchmark, and it is the highest scoring one, too. -- 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=35418 --- Comment #18 from Alexandre Julliard <julliard(a)winehq.org> --- It's hard to draw any conclusions from the total score, because as you noted, with client-side rendering output is not constantly flushed to the screen, and with X11 rendering drawing is asynchronous and the benchmark can't measure it properly. That said, back when working on the DIB engine I did spend a lot of time with 2DBench to make sure that performance was adequate, and I believe it is for all common operations. As explained above, the problem with this bug is not the drawing performance, it's the timing of the buffer flushes. -- 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=35418 --- Comment #19 from Sebastian <gustep12(a)yahoo.com> --- Created attachment 52880 --> https://bugs.winehq.org/attachment.cgi?id=52880 GDI rendering performance of Windows XP, Windows 7, and WINE With ClientSideGraphics=N, Win XP > WINE > Win 7 and animations are smooth With ClientSideGraphics=Y, Win XP > WINE = Win 7 and animations are jerky -- 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=35418 --- Comment #20 from Sebastian <gustep12(a)yahoo.com> --- WinXP WinXP Win7 Win7 WINE WINE WINE WINE WinXP WinXP Win7 Win7 WINE WINE WINE WINE Direct DIB-buf Direct DIB-buf Direct DIB-buf Direct DIB-buf CSG=N CSG=N CSG=Y CSG=Y Text: 177936 41017 22936 29223 36127 33693 55617 33807 Line: 57826 87260 33807 74701 180723 42277 34594 42397 Spline: 27949 32819 12343 32733 78555 10064 10165 10075 Polyg: 38023 14771 6661 10973 76433 16203 14833 16278 Rect: 25608 1700 2279 1084 13063 4462 4125 4480 Ellips: 21331 18498 8767 15418 19693 9193 5621 9232 Blitt: 187970 2287 5664 6653 6726 1626 10526 1665 Stret: 513 298 696 615 2300 304 745 314 Total: 6543 1956 1039 1694 4258 1309 1584 1311 Look: Smooth Jerky Smooth Jerky Smooth Jerky Smooth Jerky -- 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=35418 --- Comment #21 from Sebastian <gustep12(a)yahoo.com> --- Alexandre, thank you for your contribution. I am happy to see that with ClientSideGraphics=N, WINE on Linux performs better than Windows 7 in this GDI rendering benchmark. I think there are probably many legacy Windows applications which were expecting to do direct rendering, and maybe even employed that mechanism for smooth animations. Rendering to a buffer and displaying the final result hides many of the transient animation steps. This is a problem whenever the application renders to a DIB buffer, and it seems that ClientSideGraphics=Y forces this behavior, even when it wasn't intended by the program's creator. I wonder if it would be possible to force a buffer flush at regular intervals, maybe at 30Hz, even when DIB buffering is enabled? On the other hand, why use DIB buffering at all for GDI applications? In both XP and WINE, nearly every metric in this benchmark is significantly faster with direct rendering. Windows 7 is mediocre and can't reach XP or WINE performance - I guess Win7 forces DIB buffering regardless of the application 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=35418 --- Comment #22 from Sebastian <gustep12(a)yahoo.com> --- Sorry, I didn't mean to be overly critical of the DIB engine. I wish I had the chops to look into the code myself. Maybe at some point in the future... Thanks! -- 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=35418 --- Comment #23 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Sebastian from comment #21)
On the other hand, why use DIB buffering at all for GDI applications? In both XP and WINE, nearly every metric in this benchmark is significantly faster with direct rendering. Windows 7 is mediocre and can't reach XP or WINE performance - I guess Win7 forces DIB buffering regardless of the application setting.
It may be faster, but it's not always correct. There are many GDI operations that cannot be implemented correctly in X11. Switching to client-side rendering has fixed a lot of graphical glitches, and also improved performance noticeably in many cases. Note that X11 rendering isn't always faster. The same benchmark on my machine (GeForce 320M, nouveau driver) shows X11 being slower by a factor of 2.
I wonder if it would be possible to force a buffer flush at regular intervals, > maybe at 30Hz, even when DIB buffering is enabled?
We will probably want something like that eventually, but it's not trivial to do in the existing architecture. -- 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=35418 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bbc849df8d66b99162684dcee21 | |3b08cd67b86d0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #24 from Alexandre Julliard <julliard(a)winehq.org> --- This should be fixed by bbc849df8d66b99162684dcee213b08cd67b86d0. -- 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=35418 --- Comment #25 from Sebastian <gustep12(a)yahoo.com> --- Great, looking forwards to it. How can I test the fix? Also, I agree that rendering performance (in GDI operations per second) is important, but not the only consideration. The on-screen appearance should also be considered: 1.) Is the final screen correct? DIB may have some advantages here. 2.) Are animations fluid and responsive? Direct rendering may be better. My general impression is: With ClientSideGraphics=N, WINE emulates WinXP behavior faithfully (direct rendering) With ClientSideGraphics=Y, WINE emulates Win7 behavior (DIB buffering), but with a difference: Namely, in Tom's 2DBench.exe, Windows 7 appears to present the final image after the buffer flush for a *significantly* longer time than WINE with ClientSideGraphics=Y. The overall result appears to be: WinXP direct rendering: Fluid animation with many frames (very fast) WinXP DIB buffering: Only final frame appears (for maybe 1/30th of a second) WINE ClientSideGraphics=N direct rendering: Like WinXP direct rendering WINE ClientSideGraphics=N DIB buffering: Like WinXP DIB buffering Win7 direct rendering: Slow animation with many frames (long final frame) Win7 DIB buffering: Only final frame appears (significantly longer than XP!) WINE ClientSideGraphics=Y direct rendering: Most times nothing appears (???) WINE ClientSideGraphics=Y DIB buffering: Most times nothing appears (???) Basically, Windows 7 appears to add a small pause after the rendering is complete to ensure that it is actually displayed. In WINE with ClientSideGraphics=Y, is it possible that the buffer is either not reliably flushed, or flushed but immediately replaced with something else before it ever had a chance time to appear on the display? -- 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=35418 --- Comment #26 from Sebastian <gustep12(a)yahoo.com> --- The benchmarks and the original article on Tom's Hardware show that GDI rectangles are drawn much more slowly than GDI polygons in nearly all cases, on all OS's. Would it be possible to convert rectangles to polygons on the fly and achieve a performance increase? -- 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=35418 --- Comment #27 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Sebastian from comment #26)
Would it be possible to convert rectangles to polygons on the fly and achieve a performance increase?
Actually rectangles are faster. But of course a big rectangle will be slower than a small polygon... -- 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=35418 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #28 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 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.
participants (1)
-
wine-bugs＠winehq.org