GNOME Bugzilla – Bug 779883
Sometimes with text wraping enabled (especially for narrow window widths) differences are not calculated or scrolled to
Last modified: 2017-05-13 22:40:15 UTC
The problem is that meld sometimes doesn't behave correctly on opening. Something the behaviour is like bug https://bugzilla.gnome.org/show_bug.cgi?id=769705 (difference is visualized on side, but scrolling stops in the middle), sometimes meld hangs with rotating "processing icon" and exits it only after manual scroll to difference This issue reproduction is not very stable, and I failed getting the exact steps yet. It looks that opening file with syntax highlighting from version control in a narrow window makes bug more frequently (100% of times in some combinations). The steps with maximal probability that I found are: A)Preparation 1)open meld binary in itself by running bin/meld bin/meld 2)make a small edit in the second part of file 3)resize window to smallest available width, and normal big height 4)save and close meld b)Reproduction 1)run bin/meld bin/meld 2)It opens in a small window size (saved from previous run) 3)Sometimes bug reproduces. If it didn't - try resizing window a bit and try reproduction again. If bug reproduces first time - it reproduces every time with such size. I see this problem several times on linux and one time on windows. Both has gtk 3.18.
I've also reproduced this with GTK+ 3.22.9; it's as weird as you suggest. However, I could only get this to happen when text wrapping is enabled. With it off, everything works just fine. I suspect you're right and it's linked to the adjustment event emission from the other bug. I see the behaviour where scrolling stops very reliably. I've only seen the spinning hang once.
Discovered that when problem reproduces - the cpu usage of meld becomes 100% (of one core). The UI is not hang, so it is infinite event processing. The events raised are and DiffGrid.do_size_allocate SavedWindowState.on_size_allocate DiffMap.do_get_preferred_width DiffGrid.do_draw self._scrolladj.connect("changed",lambda w: self.queue_draw()) DiffGrid.do_size_allocate ...
Can you please see if you can reproduce this with current HEAD? A very very bad "fix" for some different insanity may have fixed this by side effect, by changing when DiffMap queues a resize. I could previously reproduce this (with some effort) and now can't any more.
Created attachment 347887 [details] Screenshot of spinning with no diff I tested current 0396666 dirdiff: Fix GTK+ allocation breakage, part X of Y on linux with gtk 3.20 - the spinning hang reliably reproduces. The other testing environments - windows and linux - have gtk 3.18, and commit ef3ba1b (diffmap: Call our correct parent init) breaks 3.18 compatibility - queue_allocate is 3.20+. So on machines with gtk 3.18 I've tested 0396666 with cherry-reverted ef3ba1b. Both windows and linux machines very often show infinite spinning on "bin/meld" (with line wrap and very narrow window) and sometimes scrolling stops. One time a infinite spinning reproduces even on a bin/meld without changes at all. It infinitely spins and syntax highligting didn't appear (see screenshot) After scrolling to the end of file - syntax highlighting and "files identical" note appears and spinning disappear.
Here are some results of not-yet-completed investigation: -the source has horizontal scrollbar! (see previous screenshot) while char wrap is enabled and bug is reproducing only with char wrap. -the spinning problem disappears after minimizing and restoring window -the spinning problem disappears if MeldSourceView overloads do_size_allocate in a way that it calls GtkSource.View.do_size_allocate first several times and then stops calling it (this obviously breaks resizing). -the length of left and right scrollbars during the spinning problem sometimes are different even files are identical - so full loading is not completed -using scrolling several times with mouse - leads to several "loading more of file data" operations and after 5-10 times when all data is loaded - leads to spinning ending. hypothesis from incomplete investigation: the problem is infinite event processing that somehow arises from GtkSource.View.do_size_allocate implementation.
I've spent really way too long looking at this. I don't have any useful conclusions. I can make this go away completely by either removing DiffGrid in favour of GtkGrid (which sucks, but might be the solution) or by removing the GSettings binding in SavedWindowState to *both* width and height. We could totally do the second of these, but it really sucks, especially since this was a change made to satisfy a window sizing ABI break in 3.22. This just feels like a debounce problem with the changed signal emissions, but I'm rapidly running out of any ability to care about GTK+'s crap at this point.
The WindowState change appears to not be enough. Currently I'm thinking that we might need to add manual debounce handling to DiffGrid.do_size_allocate.child_allocate, to try and avoid reallocating to children when their allocation hasn't changed. This is super weird, because I'd expect these changes to be related to GtkCSSGadget in 3.20, but you say you're seeing this behaviour on 3.18. However, I don't have the energy to deal with this any more currently.
I've investigated this a bit further and found following: The infinite spinning behaviour extremely rarely reproduces with gnome-shell and extremely often with gnome-flashback (metacity). Meld 3.16 contains this bug, but meld 3.14 doesn't. Git bisection says 6af28bc84658c3dbb2982dc7aaf3fbf9f753f8c1 is the first bad commit commit 6af28bc84658c3dbb2982dc7aaf3fbf9f753f8c1 Author: Kai Willadsen <kai.willadsen@gmail.com> Date: Sun Mar 6 08:04:35 2016 +1000 diffgrid: Chain up in size-allocate to avoid warning messages See bgo#762754 for some context; this is now the required behaviour. And really, commenting out "Gtk.Grid.do_size_allocate(self, allocation)" in current master seems to fix problem (and as far as I feel - improve visual performance). I didn't investigate what the commenting breaks, though. By the way - one of the commits that tries to fix this bug in current master - ef3ba1b - introduces unconditional usage of self.queue_allocate() in diffmap.py - this bumps gtk requirement from 3.14 to 3.22. I performed most of my tests with reverting it. (not all, one of my machines has gtk 3.22 and bug still reproduces there without this reverted). Is the version bump intentional?
(In reply to Vasily Galkin from comment #8) > I've investigated this a bit further and found following: > > The infinite spinning behaviour extremely rarely reproduces with gnome-shell > and extremely often with gnome-flashback (metacity). I've actually had a few very reliable reproductions now, cheers. > Meld 3.16 contains this bug, but meld 3.14 doesn't. Git bisection says > > 6af28bc84658c3dbb2982dc7aaf3fbf9f753f8c1 is the first bad commit > commit 6af28bc84658c3dbb2982dc7aaf3fbf9f753f8c1 > Author: Kai Willadsen <kai.willadsen@gmail.com> > Date: Sun Mar 6 08:04:35 2016 +1000 > > diffgrid: Chain up in size-allocate to avoid warning messages > > See bgo#762754 for some context; this is now the required behaviour. > > And really, commenting out "Gtk.Grid.do_size_allocate(self, allocation)" in > current master seems to fix problem (and as far as I feel - improve visual > performance). I didn't investigate what the commenting breaks, though. Thanks for that. That call was the result of trying to fix GTK+ warnings, with the result that apparently it's required to chain up there. I can confirm that removing the call means that the warnings occur constantly, but other than that everything continues to work fine. More generally though, this is a regression in the GTK+ 3.22.x series somewhere; it doesn't happen in early 3.22 releases, but does currently. I've tried to bisect the problem, but a bunch of uncompilable commits made this difficult. I'll try again and see where I get to on this. I suspect that in the end I'll remove the chain up that you've identified (at least conditionally on the GTK+ release) and re-silence that warning, but this is just awful. > By the way - one of the commits that tries to fix this bug in current master > - ef3ba1b - introduces unconditional usage of self.queue_allocate() in > diffmap.py - this bumps gtk requirement from 3.14 to 3.22. I performed most > of my tests with reverting it. (not all, one of my machines has gtk 3.22 and > bug still reproduces there without this reverted). Is the version bump > intentional? No, it wasn't. I've reverted that now. Thanks for noticing.
There is another minor problem that looks to be dependent on same "widgets size-allocated 2 times in DiffGrid" do_size_allocate behavior: a visible but unusable horizontal scrollbars sometimes appears at the bottom of word-wrapped code windows after widths are resized by dragging diffgrid separator. In the absense of such double allocating - the scrollbar links but diasappears. Maybe the origin of the problem is some async handling of word wrap in code widgets. It is a minor problem but is very reproducible way to see the related problematic behaviour even in gnome shell.
(In reply to Kai Willadsen from comment #9) > More generally though, this is a regression in the GTK+ 3.22.x series > somewhere; it doesn't happen in early 3.22 releases, but does currently. > I've tried to bisect the problem, but a bunch of uncompilable commits made > this difficult. I'll try again and see where I get to on this. I was wrong about this. The problem definitely remains in earlier 3.22.x releases. The symptoms were slightly different appearance-wise, so I didn't realise what I was seeing.
Thanks very much for chasing this down. I'm sorry it took so long to get a fix applied... I really just didn't want to have to use this workaround, but I'm not getting anywhere and it's becoming increasingly pointless to continue looking for a better fix. I've just pushed your suggested workaround (from comment 8) for this to current master. Given what the change is like (and how rarely this occurs in normal use) I'm somewhat reluctant to push it to 3.16.x as well, though I'm open to feedback on that.