Tilix: Scrolling is slow when history is long

[MingcongBai]

When there is a long scrollback on Terminix, the scroll is quite slow (with Trackpoint and mouse scroll wheel). And that about sums up the issue.

My Terminix is version 1.4.0-beta... Not sure if fixed in newer version.

[Salamandar]

Works fine for me and a veeeery long history.
That makes me think about a feature : a small pop-up with the lines count + position (like the page pop-up in Adobe Reader, for example)

[MingcongBai]

That would be very nice.

2017年1月3日 18:55，"Salamandar" [e-mail]写道：

Works fine for me and a veeeery long history.
That makes me think about a feature : a small pop-up with the lines count

• position (like the page pop-up in Adobe Reader, for example)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gnunn1/terminix/issues/669#issuecomment-270090481,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AExjt48c_E99nr-tsf3mNhs5otC_F8o7ks5rOikqgaJpZM4LZZZU
.

[gnunn1]

I'm a little confused, is the problem when bash history has too many or when you have a large scrollback buffer, i.e. you've been cat'ing large log files or something similar.

If the issue is with history, what's the output of this command:

env | grep HIST

If the issue is with a large scrollback buffer, what do you have set for the scroll settings for the profile you are using:

Also, do you have any triggers configured?

[MingcongBai]

I did mean the scrollbuffer, sorry for the confusion.

I did not limit the scrollback length, nor do I have any triggers enabled.

2017年1月3日 23:38，"Gerald Nunn" [e-mail]写道：

I'm a little confused, is the problem when bash history has too many or
when you have a large scrollback buffer, i.e. you've been cat'ing large log
files or something similar.

If the issue is with history, what's the output of this command:

env | grep HIST

If the issue is with a large scrollback buffer, what do you have set for
the scroll settings for the profile you are using:

[image: screenshot from 2017-01-03 10-37-54]
https://cloud.githubusercontent.com/assets/9358238/21612841/b71f6762-d1a0-11e6-9d2d-1ea7edf0260e.png

Also, do you have any triggers configured?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gnunn1/terminix/issues/669#issuecomment-270142173,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AExjt7vhSR3B4lqrGcPNTiIEFZ5rILosks5rOmtvgaJpZM4LZZZU
.

[shamil]

I experience this as well, not sure it's related to scroll-buffer, it's just become slow suddenly from time to time until I re-open the session

[gnunn1]

Is the issue only with the trackpad or scrollwheel, i.e. if you grab the scrollbar directly move it up and down does it work fine?

If so I wonder if it's related to this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=688127

Do you have any custom hyperlinks enabled? Note it could also be an issue with the default regex'es I'm using as well.

I've tried duplicating it here but no success so far.

[shamil]

Yes it happens only when using mouse/trackpad.
Not sure if it's related to the bug you mentioned, for me the problem occurs only in terminix, gnome-terminal and guake has no such problem.

[gnunn1]

@shamil Guake is GTK2 and using an ancient version of VTE so it's not comparable unfortunately. For gnome-terminal, can you confirm that the scrollback option you have set for the profile you use matches the same setting in terminix, i.e. you have unlimited scrollback set in both.

It could still be the regex's, I know @egmontkob spent quite a bit of time improving them for gnome-terminal and mine my need to be updated to match. I'll have a look over the next couple of days.

[egmontkob]

Regex updates were mostly made for functional fixes, although they might have fixed some performance issues.

It would be great to know whether there are extremely long "paragraphs" (data without explicit newline, just overflowing to the next line) when scrolling is slow. This might be a reason for poor regex performance.

I'm quite certain the issue is related to regexes; without them one step of scrolling takes a roughly fixed time, regardless of the entire scrollback size and the amount of scroll.

[gnunn1]

I've updated the regex to match what gnome-terminal is using, hopefully this does the trick. If not, please re-open the issue.

@egmontkob I copied your terminal_regex.h from gnome-terminal and adapted it for D. I have left your copyright, license and credit intact. If you have any issue with this let me know and I'll revert everything. You can view the file here:

https://github.com/gnunn1/terminix/blob/master/source/gx/terminix/terminal/regex.d

[egmontkob]

Fine by me :)

I am not a lawyer, but... the given code is GPL v3 in gnome-terminal, and hence I don't think it's compatible with terminix's MPL v2.

On the other hand, the code was written by and is copyrighted by me (I have not resigned the copyright to GNOME Foundation or FSF or similar, although I could have), and as my intellectual property I'm allowed to re-release it under any other license for any other purpose. So hereby I re-release it under MPL for Terminix. Or whatever. I re-release it under WTFPL. I'm happy if others find my work useful! :)

[gnunn1]

Thanks @egmontkob, much appreciated. I'll update the license block to match the rest of Terminix.

[arshavindn]

Seem it's not fixed yet, I run Rails server and when it has a very long content, scrolling turns to lagging. I dont set any trigger as well limit scrollback

[gnunn1]

@arshavindn Are you using the version from git, that's the where I updated the regex'es though I'm not overly optimistic it would have fixed this.

[arshavindn]

Yes, the latest version from git, but with version 1.3.5, the issue does not happen

[gnunn1]

OK, let me see what changed from 1.3.5, hopefully it will be something obvious.

[gnunn1]

In the file terminal.d, can you try commenting out this line (currently line 811) and rebuild terminix to see if it fixes the problem. So change this line:

            vte.addOnScroll(&onTerminalScroll);

to:

            // vte.addOnScroll(&onTerminalScroll);

Mouse wheel scrolling was added to 1.4.0 so it seems like a likely first candidate to look at for the problem. Maybe reading the GSetting for this is too slow on your machine compared to mine and I should cache it.

[arshavindn]

I have just rebuilt the latest version from git and the problem solved. No need to comment that line.
Thank you so much for great app!

[gnunn1]

OK that's weird, why did it start working OK now? Before getting the latest that fixed the issue, do you know roughly when you had last fetched it?

[arshavindn]

maybe it happens because of using too much RAM. Today I back to work and my computer was up for a while and it used over 5gb/8, then scrolling turned to lagging

[phw]

Just for completeness, I experience extreme lagging while scrolling with mouse wheel in one terminal currently. Using Terminix 1.4.2 on Arch.

A single terminal lags extremely. My system is not running other applications besides Terminix and Firefox, only 6 GB of 16GB are in use, no swapping, and CPU usage is down. Terminix itself has 3 sessions with a total of 8 terminals open, but no background processes running, only terminals waiting for input. Terminix consumes about 60 MB RAM. I have regexes for two use defines links and two triggers setup, triggers are limited to the last 256 lines.

But as soon as I scroll in that single terminal using the mouse wheel Terminix consumes 25% CPU (I think an entire CPU core) and the scrolling lags noticeable. Grabbing the scrollbar and dragging it however seems to work smoothly. The terminal itself has a larger scroll buffer, mostly consisting of build output from AUR package updates using yaourt.

I don't know whether I will be able to reproduce this. I am closing the terminal now, and I have never before experienced such extreme lagging, despite having frequently many terminals open over the whole day, all with long output buffers using the same profile.

[gnunn1]

@phw Thanks for the report. I just made a change to cache the value of the preference for whether to zoom on control+scrollwheel rather then fetch it from dconf everytime the scroll wheel even handler is triggered, it's the only obvious thing I can see that could be causing this.

[f2404]

My 2 cents: I tried the latest git terminix, scrolling a text file with ~8500K lines; and I noticed that CPU consumption raised up to 20% and higher when I got to half of the file. I guess it could get even higher if doing more scrolling.
Another thing is that memory consumption is also slightly going up while scrolling.

[gnunn1]

Thanks @f2404, unfortunately I cannot replicate. I'm cat'ing a text file with 166472 lines in it and not noticing any performance issues with scrolling.

When you say 8500K do you mean 8500 lines or 8,500,000 lines?

[f2404]

@gnunn1 Oops, sorry, I meant 8500 or 8,5K lines.
My test is running cat file and then scrolling it with mouse wheel from bottom to top, watching the terminix process via htop in another terminal.

[f2404]

@gnunn1 It seems that I may have been running not the latest git version when I noticed CPU load increase. At least I cannot reproduce it now.
But I'm still seeing a memory load increase.

[gnunn1]

I just checked in a change an hour ago to optimize the VTE onScroll handler where I was previously reading from DConf, so maybe that was the problem after all.

As for memory load, I know at some point the VTE should start writing the buffer out to a temporary file but I can't remember when it kicks in.

[f2404]

I just checked in a change an hour ago to optimize the VTE onScroll handler where I was previously
reading from DConf, so maybe that was the problem after all.

Yes, it could be.

As for memory load, I know at some point the VTE should start writing the buffer out to a temporary
but I can't remember when it kicks in.

I checked xfce4-terminal on the same file, and it showed no memory load growth while scrolling.

[gnunn1]

If you are building terminix yourself in debug mode, you should have a GC menu item in the hamburger menu. If you click that a few times does the memory go back to a baseline?

[f2404]

@gnunn1 I've built it with dub build --build=debug but cannot see GC menu.

[gnunn1]

Sorry you need to build it with tracing enabled as well:

dub build --build=debug --config=trace

I'll adjust dub.json so that the GC flag applies to all debug builds.

[f2404]

Thanks, I got the menu now.

Observation 1: terminix eats memory on each focus switch to another app, and this memory isn't recovered by GC.
Observation 2: when not switching to other windows and scrolling the output, memory also gets eaten and also isn't recovered by GC.

[gnunn1]

Thanks @f2404, I'll have a look into it.

[gnunn1]

@f2404 So I'm looking into that memory focus issue and while I can see the memory increase I'm stumped as where the issue is. I've tried commenting out all the event handlers and the problem is still happening. Interestingly I see the exact same behavior with gedit and nautilus.

Can you do a quick test of gedit and confirm whether or not you see the same thing there?

[f2404]

@gnunn1 Indeed, I can see the same happening with gedit; I also checked file-roller, and it showed the same. This looks like a common problem for gtk3 apps, I guess.
I wonder why this is not the case for xfce4-terminal - maybe because though it's a gtk3 app, it still has some gtk2 leftover that prevents the problem from happening...

Do you think memory increase on scrolling is the same issue as this one?

[gnunn1]

@f2404 It certainly could be related, like you mentioned I suspect xfce doesn't have an issue because it doesn't use as many of the newer widgets (Headbar, GIO actions, popovers, etc). There are a number of memory leak bug reports in the gnome bugzilla including this one, I think I'm just going to write this off as NMP (Not My Problem).

https://bugzilla.gnome.org/show_bug.cgi?id=772859

[f2404]

@gnunn1 Makes sense.