GNOME Bugzilla – Bug 164153
Scrolling issues (bugs and flickers) with solid background
Last modified: 2006-03-07 17:08:25 UTC
When scrolling the contents of the window, many bugs occur inside a vte with a solid background. Most of these bugs do not occur, however, if the background is transparent or is a pixmap (which, of course, as a special corner case may be transparent background with 100% opacity, or a solid pixmap of the desired color to appear as a soliid background, but behave without bugs in the following situations.) The core of the problem is that when the background is a pixmap, vte always performs a full screen update, however, with solid background, it tries to re-use contents of the window by scrolling the whole terminal area. I'll try to show why scrolling is buggy (both in design and in implementation) and hence should be avoided. - Bug #158797 talks about faulty pixels during scrolling. The bug only happens with solid background. Although I provided a patch there, that patch still causes some flickering. With pixmap background the behavior is perfect. - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104768 talks about a very similar case (according to the screenshot) but it's not exactly the same. The reporter states that it only happens with solid background. - Bug #120401 and bug #156935 describe that backwards scrolling in less (less-382 without its "-c" option) is extremely slow, e.g. it is nearly impossible to scroll several pages backwards in a manpage with PageUp to find what you're looking for, the screen gets easily unusable for several seconds. Yet again, that bug only happens with solid background. With pixmap background, backwards scrolling goes perfectly. - When scrolling in "less" using the Up and Down arrows, the bottom status row suffers from flickering in solid vte. When scrolling downwards the status line appears for short moments one line above the bottom one. When scrolling upwards the status line disappears for some short moments. In pixmap vte there's no flicker at all. - When viewing the growing output of a program in vte, which doesn't grow too slow neither too fast (e.g. try this: "while true; do sleep 0.001; echo $PATH; done"), and some lower parts (e.g. the bottom right quarter) of the vte window are obscured by other windows, then several lines above this obscured part suffer from flickering. Each time there are some lines of new output, this area becomes background-colored for a short moment and content is put there later. Similarly the bottom of the whole vte window flickers even without partially obscuring the window. All these flickers do not occur with pixmap background. I don't know if scrolling the terminal area could be implemented without all these transient and permanent bugs, but I don't think it is worth it at all. Alternate source code trying to reach the same goal but in a perfectly different way may lead to stupid bugs as we see here. Full repaint of the window instead of scrolling seems to be only slightly slower to me in normal circumstances than using gdk's scroll function (however, if speed is an issue, there are several speedup patches for vte, e.g. in bug #143914 and bug #122656 which are worth applying), and in some cases (backwards scrolling in less) the pixmap method of redrawing is much faster. And generally it is much better to the eyes since it doesn't flicker. See the attached patch. It drops the gdk_window_scroll code and always executes the screen updating code that is normally executed for pixmap background. With this patch, all the problems linked/described above are gone.
Created attachment 36052 [details] [review] the patch
Comment on attachment 36052 [details] [review] the patch This doesn't apply after the recent changes. Could you recheck and adjust the patch if it's still relevant?
Please don't only blindly try to apply my patch, please first try to understand what and why this patch does and what's wrong with vte 0.11.11. I've tried current CVS and while hardly any (maybe none) of the bugs described in this bugreport are solved, many new and serious scrolling bugs appeared. I recommend you to first drop all the patches that conflict with this one and then apply my one. My patch has already survived a lot of testing since I'm a developer of a Hungarian distro where we offer Gnome and hence gnome-terminal by default to all our users and none of them had reported any scrolling problems. (If you're interested, you find all our current patches to vte at https://svn.uhulinux.hu/packages/dev/vte/patches/ , these patches form a really good and tested patchset to vte 0.11.11.) With the current vte cvs it took me no more than half minute to find really serious scrolling problems. E.g. just press Return many times at the bash prompt, when the window starts scrolling the cursor remains there in upper lines, too. The "while true..." command shown above produces really stupid output. "man bash" brings up less's prompt both in the top and the bottom lines and when you start scrolling it it becomes worse. There're many many bugs like these ones. Current CVS is even much worse than mainstream unpatched 0.11.11. Kind of unusable. These are so obvious errors that sure anyone will face them within a few minutes, so I wouldn't bother with filing a separate bug report. Please trust me. If you take a look at my vte patches in gnome bugzilla, you'll find that I've already spent a huge time fixing some vte bugs even though I'm not a Gnome developer. I just use gnome-terminal 8 or 10 hours a day (usually I have around 10-15 of them open at a time) and offer it to many other people, so it's very important for me that vte worked as fast and bugfree and flickerfree as possible and I've done my best I could. Try to patch vte 0.11.11 with the patches at the url I've just written above and compare it with unpatched 0.11.11 tarball and with current cvs, check for speed issues at forward and backward scrolling, extra pixels, flickers described here etc. I'm sure you'll find my patch collection far the best of these three possibilities. I'm very happy to see that after a year finally vte has a maintainer but please try to understand that I've already spent much more time with vte than with an average piece of software and I don't have time to test each and every cvs version, especially if they have bad, untested and trivially faulty patches which conflicy my ones. I've already done to vte all that I could, I cannot assist in verifying these patches, porting them to new cvs codebase, resolving patch conflicts with new and very buggy modifications etc... I'd rather let you, Gnome developers take this job. I hope you understand it and don't take it as an offense since this is not what I wanted. It's only that I think I've done everything I could so it shouldn't be a problem for you to fix these bugs without asking further work from me. Good luck! :)
Just a small hint: as described in the last two paragraphs of my initial report, my patch only removes code, doesn't add anything. The lines starting with "+" in the diff file are only there because I properly re-indented the code.
I filed a separate bugreport, namely bug #169766. Kjartan Maraas: do you receive e-mails about this bug at all? I don't see you on the cc list. Please add yourself to this bug as well as the other bug I've just linked.
Created attachment 45738 [details] [review] the previous patch ported to 0.11.13 Most of the issues reported in this bug are still present in 0.11.13. I attach an updated version of the patch, even though I still can't believe that a developer wasn't able to port it to the new codebase in less than one minute.
Please note that URL mentioned above: https://svn.uhulinux.hu/packages/dev/vte/patches/ always contains the current version of our vte package, which has just been upgraded to 0.11.13. The version I was talking about in comment #3 (vte 0.11.11) is available from now on at https://svn.uhulinux.hu/packages/1.2/vte/patches/
Well, I'm hardly the maintainer of vte by any stretch of imagination. I just applied the patches from the fedora package and a few others that were pretty straight forward. Sadly a bad patch from Fedora slipped in, but that has been reverted in 0.11.13 and hopefully most of the newly introduced scrolling bugs with it. Thanks a lot for providing these patches though.
Yes, that particular malness of 0.11.12 is closed now, fixed in 0.11.13, which is definitely far better than 0.11.11 or 0.11.12. However, there are still some issues with scrolling in 0.11.13, what this bugreport is mostly about, which are fixed by my patch provided here. I'm kindly waiting for you (or anyone else with cvs access) to verify and apply it. (Sorry if I was a bit too overheaded in my reactions sometimes...)
I'll add the patch to CVS to make sure it gets wider testing. And don't worry about getting emotional every once in a while, that's just normal and shows that you care :) Is this patch just about shortcutting an optimization really? And is it going to affect performance?
Yes, it's about shortcutting a buggy alternative execution branch. I don't know whether or not that one is supposed to be an optimization. I guess it is, but it is only hardly faster in normal circumstances according to my tests, while it is much more buggy and much slower in some situations. Even if it gets 20% slower or such, I believe it is worht it regarding what we gain with it. Still very easily testable, please give it a try with and without this patch: within a tall window (say, 60 lines) view a large text file with "less" (e.g. "less /etc/services" or "man bash"), go to its end by G or the End key, then tap on PageUp and hold it down for a few seconds and then release it. You'll surely see the big difference.
The patch was committed on 2005-04-29, so it's fixed since 0.11.14 or so. It's okay to close this bug. (Seems I have no permission to do that.)
Thanks!