I've tried this now (just as a user; haven't looked at the code). A couple of remarks:


(In reply to Christian Persch from comment #10)

> Do I understand correctly what this does: if adjustment is at value v_0 and,
> either programmatically, or by user interaction, should now be v_1, the
> value is animated progressively from v_0 to v_1 instead of being set
> directly to v_1?
> 
> If so, I don't see how this is a desirable thing for a terminal. This means
> that we'll have to load, decrypt, decompress, decode a whole range of
> intermediate scrollback content just to display it for 1/60th of a second...
> can this part be disabled programmatically ?

This is what happens currently if you drag the legacy scrollbar, and it was never raised as an issue. The animation is quite smooth with a 10k scrollback and is a cool eye-candy and is consistent with the rest of the apps. Consider a file manager with tons of files and icons to display for them based on mime type, or even actual thumbnail for pictures. I don't think rendering the content is any cheaper there. So I wouldn't be worried about this.

I'm not sure if the scrollbar's implementation is clever enough (but if not then it should be made smarter) to skip frames if the app is slow rendering.


> How does this interact with selection, dingus, or mouse tracking mode?

I haven't seen any problem here (apart from the obvious that starting the selection in the last column becomes troublesome).


(In reply to Carlos Garnacho from comment #12)

> > If so, I don't see how this is a desirable thing for a terminal. This means
> > that we'll have to load, decrypt, decompress, decode a whole range of
> > intermediate scrollback content just to display it for 1/60th of a second...
> > can this part be disabled programmatically ?
> 
> This is just true if changing between distant regions of the buffer. I
> wouldn't think this is the most usual operation? Wouldn't this be acceptable
> for PgUp/Down increments?

You're right. For PgUp/Down increments we hardly ever load/decrypt/decompress, since the most recently read 64 kB chunk of the scrollback buffer is cached in its decrypted/decompressed form.


By the way: PgUp/Down animates the scrolling in Files, but not in g-t (Shift-PgUp/Down). No clue what it'd take source code wise to change it, but it would be cool to see that behavior.


(In reply to Christian Persch from comment #15)

> Selecting usually is a vertical swipe.

Could you please elaborate? Isn't that a vertical simple mouse movement? (mouse: move vs. scroll wheel; touchpad: one vs. two fingers)


> And in (full) mouse tracking mode,
> *all* events need to be send to the terminal.

I see no behavioral change here. In mouse tracking mode, vertical scrolls are sent to the terminal.


(In reply to Debarshi Ray from comment #16)

> How about adding an option in preferences to toggle the overlay-scrolling ?

Do we need that?  Even though not user-friendly to set, making an overlay scrollbar non-overlay is just a matter of CSS.  E.g. set the overlay scrollbar's width to 5px and vte's right padding to 6px, voilà, it no longer overlays the actual content :)


One thing I find terribly irritating, but it could also be just a CSS issue. At least in Ubuntu Wily's default desktop (Unity, Ambiance), the scrollbar appears as soon as I move the mouse or produce output (the adjustment's parameters change), and disappears after a short inactivity. This results in a continuous flicker of a prominent orange-ish color.

My expectation: moving the mouse somewhere not over the scrollbar, or changing the terminal's contents (and implicitly scrolling by producing output) shouldn't change the look of the scrollbar, apart from the necessary adjustment of its height. A prominent change in appearance (color and/or width) should only occur if I move the mouse there, or scroll explicitly with a keycombo. Is it solveable with overlay scrollbar?