Re: [dev] [st] 0.3 release

From: Christoph Lohmann <20h_AT_r-36.net>
Date: Thu, 08 Nov 2012 17:09:45 +0100

Greetings.

On Thu, 08 Nov 2012 17:09:45 +0100 Brandon Invergo <brandon_AT_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
Received on Thu Nov 08 2012 - 17:09:45 CET