Scrollback with Shift-PageUp Shift-PageDown does not refresh screen

Bug #1460062 reported by David Kastrup
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-terminal (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I am often using Scrollback in GNOME-Terminal. The current version forgets to refresh the screen timely afterwards. For one thing, it means that one is wildly pressing Shift-PageUp Shift-PageDown too often and it is hard to find things.

For another, when trying to highlight material with the mouse, the refresh happens after the highlighting completes so the highlighted material is on a different page than the material you _imagined_ to be highlighting.

Very annoying. Basically, you have to remember to do an extra click or keypress or whatever in order to trigger the screen refresh before you can do anything serious.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: gnome-terminal 3.14.2-0ubuntu3
ProcVersionSignature: Ubuntu 3.16.0-34.47-generic 3.16.7-ckt8
Uname: Linux 3.16.0-34-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: i386
CurrentDesktop: X-Cinnamon
Date: Fri May 29 14:56:07 2015
InstallationDate: Installed on 2011-10-14 (1322 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111011)
SourcePackage: gnome-terminal
UpgradeStatus: Upgraded to vivid on 2015-04-27 (32 days ago)

Revision history for this message
David Kastrup (dak) wrote :
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

There are some known glitches with highlighting, but I'm not sure I understand your situation.

Let's start with the simplest one: no highlighting, just Shift+Page{Up,Down}. How does the bug occur exactly? How can I reproduce it? (I'm using these keys all the time and never had a problem, except for https://bugzilla.gnome.org/show_bug.cgi?id=160127).

Revision history for this message
David Kastrup (dak) wrote : Re: [Bug 1460062] Re: Scrollback with Shift-PageUp Shift-PageDown does not refresh screen

Egmont Koblinger <email address hidden> writes:

> Let's start with the simplest one: no highlighting, just
> Shift+Page{Up,Down}. How does the bug occur exactly? How can I reproduce
> it? (I'm using these keys all the time and never had a problem, except
> for https://bugzilla.gnome.org/show_bug.cgi?id=160127).

Basically, when using Shift+Page{Up,Down}, the display tends to lack one
keypress behind. So if you change direction, it appears as if the first
move is in the wrong direction.

It may well be relevant that I am using Cinnamon as my desktop. Maybe
it is less generous with expose or other events.

It also helps if there is no other action on the screen (no other
window). My terminal window is always vertically maximized and there
are several terminal tabs in it. It's not perfectly reproducible, but
doing S-PageUp and S-PageDown several times in a row is rather likely to
trigger it. Sometimes the cursor blinking causes a refresh, so it's
also more likely with the cursor off-screen.

--
David Kastrup

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

Sounds really interesting.

Any chance of this being the same as https://bugzilla.gnome.org/show_bug.cgi?id=730763 ?

Could also indeed be an issue related to Cinnamon. Can you try to reproduce under a different WM?

Can you download vte-0.38.3, compile with "./configure --enable-debug; make" and launch with "./src/vte-2.91", does it also misbehave? If so, start with "VTE_DEBUG=all ./src/vte-2.91", do you see the entire window flashing up in red for each Shift+PageXx keypress, and is the result still buggy?

Is there output produced between the Shift+PageXx keypresses, or is it irrelevant?

Revision history for this message
David Kastrup (dak) wrote :

I'm pretty sure by now that this issue has been video-driver or compositor related. After upgrading to Wily and a different NVidea driver, it seems to have disappeared. Prior to that, I noticed lag for several other operations, like scolling in browser windows, with the result being unconsistent until one moved around enough with the mouse or did other operations that might fill some small pipeline to the point of flushing.

So I'm pretty sure that this bug is not actually GNOME terminal related. It may just be that GNOME terminal got more economical with its redrawing/refresh and thus made it more likely to leave the uncompletely flushing rendering pipeline in a state where the visual feedback was not-yet-helpful.

Sorry for the noise.

Changed in gnome-terminal (Ubuntu):
status: New → Invalid
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

No worries; thanks for letting us know!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.