[BZ#782967] Infinite spinning and high cpu usage while simultaneously show spinners in multiple maximized windows (loading several diffs)

Submitted by Vasily Galkin

Description

Created attachment 352373 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

Patch 352373, "patch from Kai (for analyzing situation, not for an issue resolution)":
0001-meldwindow-Add-our-scheduler-idle-hook-with-higher-p.patch