GNOME Bugzilla – Bug 730599
Update problem with img.sh on large terminal
Last modified: 2014-05-27 20:12:26 UTC
perf/img.sh's output is recorded in a text file and then cat'ed. The terminal is very large (340x82), the image is even a bit taller (114 rows). After a couple of attemps to cat it, moving home the cursor sometimes by typing "reset", sometimes by pressing ^L, at one point the display is not properly updated. Only a small part of the image is scrolled upwards, the rest stays where it was originally printed and doesn't scroll. It's a temporary display updating problem, fixed by highlighing with mouse, losing focus etc. The ring seems to be is intact. g-t-3.12/vte-0.36. I couldn't yet reproduce with master, but I can't recall any relevant changes, so I'm afraid we still have the bug.
Created attachment 277015 [details] the file I'm cat'ing
Screencast: http://youtu.be/vEqDYEXx308 (bug starts at 0:39)
Could reproduce once with master.
Can reproduce now quite reliable. I set an even smaller font size (master's app.vala, then Ctrl+KP_Minus 5 times) and a large window size (~250x80), and execute »reset; cat xblast.txt«, most of the time the screen corruption occurs when I execute this command for the 2nd time in the terminal. Sometimes only at the 3rd or 4th time, but never at the first.
The problem is worse, actually there is permanent data corruption. Execute »echo -ne '\ec'; cat xblast.txt«, and notice that one of the lines is longer. Highlighting with mouse reveals that part of an escape sequence is printed literally (e.g. "55;255;48;2;255;255;255m"). I've no clue yet if these two problems are related, but both seem to be tied to resetting the terminal.
The data corruption problem is independent. I'll file another bug for that, let's keep this for the original problem.
Created attachment 277193 [details] [review] Fix In order to reproduce, it's important to always use an image with the same height. The bug is reproducible by alternating two images of equal height, but not with two images of different heights. Reseting the terminal rather than just moving the cursor home or clearing the screen is also necessary. When a newline is printed at the bottom (and the scrollbar is also at bottom position), the cells are not invalidated immediately by design. Instead, an update timeout is scheduled to move the scrollbar to the new bottom. After that timeout, the Gtk scrollbar will notify us that the scroll position changed which in turn causes the invalidation and the repaint. (This makes sense, since if we're scrolled back, the visible contents won't change.) When the terminal is reset, the scroll position is not correctly set back to 0. Due to the way we rely on this Gtk+ kick back mechanism, it's not allowed to set scroll_delta directly, it always has to happen via vte_terminal_queue_adjustment_value_changed() which schedules to actually notify the scrollbar widget about it, and stuff. So the problem is that we don't properly store the new value of the scrollbar position right after the reset, so after cating the same picture it might seem that the scrollbar never actually moved and hence no invalidation is required. We need the exact same hack we once had in bug 676075. Also, bug 709089's refactoring would really simplify our lives.
Comment on attachment 277193 [details] [review] Fix Committed as 8fbb972.
Awesome. Thanks!