Re:Windows platform: simultaneous opening 4-10 difffs leads to infinite spinning with meld checkout and pygobjectwin32 3.18.2 (with workaround)

[Vasily Galkin <galkin-vv yandex ru>]

Continued at https://bugzilla.gnome.org/show_bug.cgi?id=782967

> On 19 May 2017 at 02:33, Vasily Galkin <galkin-vv yandex ru> 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