GNOME Bugzilla – Bug 782967
Infinite spinning and high cpu usage while simultaneously show spinners in multiple maximized windows (loading several diffs)
Last modified: 2017-12-13 19:25:44 UTC
Created attachment 352373 [details] [review] patch from Kai (for analyzing situation, not for an issue resolution) Initially I started this discussion on mailing list, but now copy-pasting and continuing here, since the problem appears to be a combination of non-meld problem (gtk on windows performance) and a bit non-typical meld behaviour (running multiple maximized windows with a spinner in each from one thread). (citing last letter and attaching patch from it; more comments in other messages) > On 19 May 2017 at 02:33, Vasily Galkin wrote: > >> Hello. I found and issue with running meld checkout on windows (both master and meld-3-16) with some pygobjectwin32 3.18.2 build. >> >> Using integration with a TortoiseSvn a meld can be called to show differences for several files - the several meld processes are started simultaneously. >> This works fine for 1-3 files, but leads to infinite spinning without file loading completion for more files. >> With 6 files on my environment the infinite spinning always beginning. >> >> Unlike problem about resizing events looping (https://bugzilla.gnome.org/show_bug.cgi?id=779883 ), >> this case doesn't depend on word wrap. >> >> For me it is 100% reproducible with a command in a cmd session from a clean meld checkout. >> for %f in (1 2 3 4 5 6) do start "" py bin\meld bin\meld >> >> This opens 6 windows, the GtkSourceView doesn't make progress in source loading and the spinner is rotating in all those windows. >> The only one python.exe is running, with it's main thread being running ~70% of wall clock time. >> According to a profiler most of the time is spent in BitBlt (WINAPI rendering) function inside some cairo calls >> (don't know exact because my dll is without debug info). >> >> So, it looks like 6 windows consumes lot of cpu time on rendering spinner (on a only-5-years-old hardware), so no idle-events are raised by gtk. >> >> And indeed - it's spinner rendering: workaround by commenting out self.spinner.start() in meldwindow.py resolves the issue - the diffs are loaded very fast! >> Note that other aspects of meld gui including smooth scrolling and other animations looks pretty good, so gtk on windows is usable. >> >> I failed to reproduce the problem with meld.exe from meld 3.16.2 release, so it looks like pygobjectwin32 version does matter. > > So this seems pretty weird, and like you suggest seems to me like a > GTK+/GLib bug, but it's hard to know yet. > > The only thing that comes to mind (other than not having a progress > indicator, which I don't want to do) is that we could add our idle > loop that does difference calculations at a higher idle priority. > Could you try the attached patch and let me know whether it fixes the > problem for you? Even if it does I'm a little concerned about applying > it, because there could be weird interactions caused by pulling our > idle calculations (which include diffs, etc.) above GTK+'s size and > layout calculations. > > cheers, > Kai
Comment on attachment 352373 [details] [review] patch from Kai (for analyzing situation, not for an issue resolution) Hi. the changing-priority-patch fixes the infinite spinning issue, but introduces more serious: the change marks on the left and right margins are drawn in wrong place (after priority change the sourceview loading & line-counting is not finished at the time meld places them). Also spinners are not shown at all))) Because until idle work is done - the entire window is drawn as flat gray area. Changing priority from GLib.PRIORITY_HIGH_IDLE to GLib.PRIORITY_HIGH_IDLE+20 resolves this, but doesn't affect the sourceview loading problem. After experiments with the simplest spinner application from a https://python-gtk-3-tutorial.readthedocs.io/en/latest/spinner.html I found that problem appears when application is showing spinners in several maximized windows - every window consumes near 30% of wall clack time in main thread. Window sizes do matter: it looks like painting is doing something proportional to the painted window area, not only spinner's area. So the a bit special thing that meld is doing - running several spinners in different (possibly) maximized windows from single thread. Also, by now I'm not sure that issue is windows-specific, since I found my linux machine doesn't rotate spinners (so no CPU consumption) at all due to some gtk settings.
Created attachment 352374 [details] sample application demonstraing the gtk performance problem Usage: -run application -resize all windows to near-maximum size (yet not-maximized, to limit possible window manager optimizations) -notice that number in console is fast growing -start all spinners in all windows -if the gtk version&platform combination is problematic - the terminal output stops. It reproduces issue on the windows+gtk 3.18.2; I hope that i'll perform tests in some other combinations.
I've just tested this locally with 3.22.12 on linux, and there's no obvious problem. I'm going to strongly suggest that if you can reproduce this on Windows with just the example application you've attached (and on a current GTK+ 3 version) then this is definitely a GTK+ bug. I agree that technically what Meld is doing is "special", but... not really that special. I can also imagine ways that we *might* be able to work around this, but they're all really quite unpleasant, since the multiple spinners are essentially just causing the main loop to never hit idle.
I can't reproduce this on linux by now, too. Also I tested that gtk 3.22.15 on windows (from msys2-mingw64 builds) with a sample application - contains the problem.
While experimenting with meld on another windows machine I found another appearance of the same performance problem (at least while comparing folders). While using medium-GHz CPU from 2012 with *single* meld window occupying most of the screen on high resolution (meld window occupies more than 6 MPixels) - the infinite spinning appears (main thread is never idle since it is redrawing, so meld tasks are never processed). So, with current GTK+ 3.22.26 from msys2 there is quite annoying problem with "not-very-fast cpu + high resolution" hardware combination on windows. In short: meld is unusable on windows with 4K monitors unless a workaround is applied. Workaround is making meld window smaller. It's simple, but unfortunately isn't obvious to discover.
So it definitely sucks that we're doing critical things on idle... we should stop doing that, but it's genuinely difficult. The task queueing that Meld currently uses is basically an idle queue that we expect to be processed in a particular order, so we can't just pull things out to their own GTasks or whatever without paying quite a lot of care to the ordering. At this point, "hide the spinner on Windows" seems like a sane solution, but that bit *still* feels like a GTK+ bug to me.
The current case with 4k monitor is definitely gtk "performance bug". By the way I tested some gtk versions today and become confused by now, since failed to reliably reproduce bug on the version I thought I used before. Maybe I missed something, would be retesting with sample app. So chances are that there is some version that is new enough and doesn't has this bug.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/133.