Continued at https://bugzilla.gnome.org/show_bug.cgi?id=782967
> On 19 May 2017 at 02:33, Vasily Galkin <[email protected]> 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 _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
