Greetings. On Thu, 08 Nov 2012 17:09:45 +0100 Brandon Invergo <bran...@invergo.net> wrote: > > On 02.11.2012 20:12, Christoph Lohmann wrote: > >> * New drawing code, which is way more faster and comparable to the > >> other terminals out there. > > > > It totally is, and now im impressed. And a bit humbled, since i tried > > for some time for myself and failed ;) > > It's still not perfect, but unfortunately I have had no time to look > into it at all lately. I have a good idea of where the problem is > though. > > First, to see what I'm talking about: > 1) Open a terminal and start some CPU monitor (ie top or htop) > 2) Open another terminal and load a rather large man page (try > termcap(5)) > 3) Start scrolling down on the man page and watch your Xorg process's > CPU usage spike. Depending on how fast your computer is, this can be > anywhere from ~10%-75% CPU usage (15% on this quad-core Intel Core2Pro, > 75% on my 800mhz Arm Cortex A8) > 4) Try the same experiment with xterm or urxvt: no CPU spike
When viewing termcap(5) in st or xterm and doing some fast scrolling re‐ sults in a spike of 3% CPU in both cases. Is there any good benchmark to test this? > The problem is that in its drawing functions, st does *at least* one xlib call > per terminal line. When you factor in any change in text properties > (color, italics, etc), then you get even more xlib calls per line. When > you're scrolling, and thus redrawing the entire terminal repeatedly, > that adds up to a hell of a lot of library calls. This will get more for wide‐character support. Then the width has to be changed based on the character value. I can’t decide yet how to solve this. The problems did not appear for me, but when they do I will solve them. But that’s how all development in st happens. Sincerely, Christoph Lohmann
