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

Continued at

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 
With 6 files on my environment the infinite spinning always beginning.

Unlike problem about resizing events looping ( ),
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 
(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 
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]