Re: [dev] st features that'd be nice

[Eckehard Berns]

> ..., which would be a good starting point to trace
> the problem (unless someone already knows what the problem is).

I would assume the problem is the excessive redrawing of the whole
terminal window. Each time you move the curser only one cell the whole
screen will be redrawn into a backup pixmap and then the whole pixmap
will be copied to the window.

Also, when the screen is redrawn by the application (maybe due to a page
up/down) st's draw() will be called multiple times due to the kernel
buffer size of pipes, which will result in redrawing the entire window
multiple times.

I have experimented with remembering the min and max row of changes
since the last call to draw() (and only drawing that portion of the
screen) a while ago. It adds a few lines to the code but on my system it
did lower the CPU usage of X. I stopped looking into this because I have
other issues with st besides performance at the moment (mainly xterm
compatibility - I ssh into a few machines and installing a new terminfo
everywhere is no option for me).

-- 
Eckehard Berns

Re: [dev] st features that'd be nice

[Nick]

On Wed, Oct 19, 2011 at 09:51:33AM -0400, Andrew Hills wrote:
> Recently I have discovered that, independent of the value of $TERM, I
> am unable to use ^C or ^\ to kill tail when following a file. I am
> required to ^Z, kill %%. However, no other program seems to have this
> problem. Has anyone else seen this behavior?

^C of tail -f works fine here.

Re: [dev] st features that'd be nice

[Andrew Hills]

On Wed, Oct 19, 2011 at 9:17 AM, Nick  wrote:
> st has no performance issues. The computers are slow, by
> modern standards (900Mhz CPU).

Right, and I have a similar speed and font size (and no issues), yet
users with faster machines experience degraded performance. I'm
wondering if they have significantly more characters (read: orders of
magnitude more) drawn, which would be a good starting point to trace
the problem (unless someone already knows what the problem is).

At work I use a 1600x1200 resolution and also have no performance
issues, but I also am using Xming or VNC and running it on large
expensive machines, so it's not a good comparison.

Recently I have discovered that, independent of the value of $TERM, I
am unable to use ^C or ^\ to kill tail when following a file. I am
required to ^Z, kill %%. However, no other program seems to have this
problem. Has anyone else seen this behavior?

--Andrew Hills

Re: [dev] st features that'd be nice

[Nick]

On Wed, Oct 19, 2011 at 09:06:25AM -0400, Andrew Hills wrote:
> The computers are fast, or st has no performance issues (and is thus fast)?

st has no performance issues. The computers are slow, by
modern standards (900Mhz CPU).

Re: [dev] st features that'd be nice

[Andrew Hills]

On Wed, Oct 19, 2011 at 8:30 AM, Nick  wrote:
> It isn't. I use terminus 16 on my computers, one with an
> Intel gfx card, one with an nVidia one, and they are both
> quite fast.

The computers are fast, or st has no performance issues (and is thus fast)?

--Andrew Hills

Re: [dev] st features that'd be nice

[Nick]

On Wed, Oct 19, 2011 at 08:24:22AM -0400, Andrew Hills wrote:
> I will check tonight. Of note is that I use a
> rather large font in my terminal to avoid straining my eyes--Terminus
> 12 or 14. This may be related.

It isn't. I use terminus 16 on my computers, one with an
Intel gfx card, one with an nVidia one, and they are both
quite fast.

Re: [dev] st features that'd be nice

[Andrew Hills]

On Wed, Oct 19, 2011 at 5:59 AM, Stefan Mark  wrote:
> This problems seems to be related to the radeon video driver

My notebook has a Radeon card (Mobility X1400, I think), but I forget
which driver I am using. I will check tonight. Of note is that I use a
rather large font in my terminal to avoid straining my eyes--Terminus
12 or 14. This may be related.

--Andrew Hills

Re: [dev] st features that'd be nice

[Stefan Mark]

On 18.10.2011 18:39, Andrew Hills wrote:
> On Tue, Oct 18, 2011 at 9:13 AM, Stefan Mark  wrote:
>> For me, performance is the main issue. Drawing of 'mc' on higher
>> resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
>> a reasonable fast machine. Drawing 'top' took a bit less, but not much.
>> When doing so, st itself uses nearly none cpu time, but x11 took around
>> 97%. (using st 0.1.1)
> 
> Strangely enough, at 1400x1050 on a Pentium M laptop running at 1GHz,
> I find no performance issues running top, with a CPU usage somewhat,
> but not significantly, higher than xterm's (for both st and X). This
> is with st tip and 0.1.1.
> 
That sure is strange. Even in a small window (around 80x30), mc took
about 1s to render for me. Just typing in the last row makes X consuming
around 20% (on a 2.6ghz core2). The strange thing is, typing in the
first row only needs 6%.
This problems seems to be related to the radeon video driver, cause it
not happens on my Notebook, which has Intel graphic. I will test it on a
nvidia soon.

Re: [dev] st features that'd be nice

[Suraj N. Kurapati]

On Tue 18 Oct 2011 11:01:07 AM PDT, Nick wrote:
> * Find - search through scrollback (maybe using regex).

I find this to be one of URxvt's killer features.  Alt-S brings up
an interactive regexp search of the scrollback buffer: urxvtperl(3).

-- 
To understand a program you must become both the machine and the
program.


signature.asc
Description: PGP signature

Re: [dev] st features that'd be nice

[Andrew Hills]

On Tue, Oct 18, 2011 at 9:13 AM, Stefan Mark  wrote:
> For me, performance is the main issue. Drawing of 'mc' on higher
> resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
> a reasonable fast machine. Drawing 'top' took a bit less, but not much.
> When doing so, st itself uses nearly none cpu time, but x11 took around
> 97%. (using st 0.1.1)

Strangely enough, at 1400x1050 on a Pentium M laptop running at 1GHz,
I find no performance issues running top, with a CPU usage somewhat,
but not significantly, higher than xterm's (for both st and X). This
is with st tip and 0.1.1.

Using st as an xterm replacement for some time, I found that the
missing scrollback buffer is unimportant to me, so long as I have
less, and the only real workaround I use is telling vim that it's
running in an xterm.

--Andrew Hills

Re: [dev] st features that'd be nice

[Manolo Martínez]

On 10/18/11 at 03:13pm, Stefan Mark wrote:
> On 18.10.2011 13:15, Peter John Hartman wrote:
> > Here's a feature request that should go in first: make st usable.
> > 
> For me, performance is the main issue. Drawing of 'mc' on higher
> resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
> a reasonable fast machine. Drawing 'top' took a bit less, but not much.
> When doing so, st itself uses nearly none cpu time, but x11 took around
> 97%. (using st 0.1.1)
> 
FWIW, I'm part of (I think) a growing trend of undaunted newbies: I run dwm and
mostly text programs, but my scripting abilities are, well, limited.

I gave st a try the other day, and yes, consulting my mutt mail took forever.

Cheers,
Manolo
-- 

Re: [dev] st features that'd be nice

[Stefan Mark]

On 18.10.2011 13:15, Peter John Hartman wrote:
> Here's a feature request that should go in first: make st usable.
> 
For me, performance is the main issue. Drawing of 'mc' on higher
resolutions (1600x1200 or 1920x1080) tooks about 10s (sometimes more) on
a reasonable fast machine. Drawing 'top' took a bit less, but not much.
When doing so, st itself uses nearly none cpu time, but x11 took around
97%. (using st 0.1.1)

Re: [dev] st features that'd be nice

[Peter John Hartman]

On Tue, Oct 18, 2011 at 11:01:07AM +0100, Nick wrote:
> I just read about terminator
> , and thought a
> couple of its features sounded worth stealing (both require
> scrollback to be implemented):
> 
> * Logging - logs of terminal sessions can be saved. It only
>   makes sense to do this on command, rather than automatically
>   (as terminator does). Once scrollback exists, this becomes
>   pretty easy (just save that).
> 
> * Find - search through scrollback (maybe using regex).
> 
> Another nice thing to have would be:
> 
> * Smart reflowing of text on window resize. I think OSX's
>   terminal emulator might do this.
> 
> None of these should take much code, I think. I'd like to
> add these myself, but I'd like it even more if someone else
> did.

The logging and find are both things that tmux does, and to do them right it
does take a chunk of code.  Why should st do them?  I can't think of any
reason.  Here's a feature request that should go in first: make st usable.

Peter



-- 
sic dicit magister P
University of Toronto / Fordham University
Collins Hall B06; Office Hours TF10-12
http://individual.utoronto.ca/peterjh
gpg --keyserver pgp.mit.edu --recv-keys E0DBD3D6 

Re: [dev] st features that'd be nice

[Nick]

On Tue, Oct 18, 2011 at 12:11:55PM +0200, pancake wrote:
> On 10/18/11 12:01, Nick wrote:
> >* Logging - logs of terminal sessions can be saved. It only
> >   makes sense to do this on command, rather than automatically
> >   (as terminator does). Once scrollback exists, this becomes
> >   pretty easy (just save that).
> use script, ytscript or ttyrec.

The advantage of doing it in the terminal (once it has
scrollback) is that you can decide after something
interesting has happened "and save that", rather than
running one of those before. (though I'm not very familiar
with any of those tools).

> >* Find - search through scrollback (maybe using regex).
> we have no scrollback, and we delegate this task to
> >Another nice thing to have would be:
> >
> >* Smart reflowing of text on window resize. I think OSX's
> >   terminal emulator might do this.
> that would be cool if we supported scrollback. which is imho the
> main reason i dont use st as my main terminal

Yeah, I meant to imply above that scrollback is a more
important feature, that I'd particularly like.

Re: [dev] st features that'd be nice

[pancake]

On 10/18/11 12:01, Nick wrote:

I just read about terminator
, and thought a
couple of its features sounded worth stealing (both require
scrollback to be implemented):

* Logging - logs of terminal sessions can be saved. It only
   makes sense to do this on command, rather than automatically
   (as terminator does). Once scrollback exists, this becomes
   pretty easy (just save that).

use script, ytscript or ttyrec.


* Find - search through scrollback (maybe using regex).

we have no scrollback, and we delegate this task to

Another nice thing to have would be:

* Smart reflowing of text on window resize. I think OSX's
   terminal emulator might do this.
that would be cool if we supported scrollback. which is imho the main 
reason i dont use st as my main terminal


None of these should take much code, I think. I'd like to
add these myself, but I'd like it even more if someone else
did.

Nick

[dev] st features that'd be nice

[Nick]

I just read about terminator
, and thought a
couple of its features sounded worth stealing (both require
scrollback to be implemented):

* Logging - logs of terminal sessions can be saved. It only
  makes sense to do this on command, rather than automatically
  (as terminator does). Once scrollback exists, this becomes
  pretty easy (just save that).

* Find - search through scrollback (maybe using regex).

Another nice thing to have would be:

* Smart reflowing of text on window resize. I think OSX's
  terminal emulator might do this.

None of these should take much code, I think. I'd like to
add these myself, but I'd like it even more if someone else
did.

Nick