Re: [dev] [st] Drawing optimizations

2012-01-23 Thread Aurélien Aptel
On Sun, Jan 22, 2012 at 7:22 PM, Peter John Hartman wrote: > Hi, > > Unfortunately, the tmux-split-pane problem still persists.  The > tmux-split-pane problem is this: if one pane in tmux is spitting > out a bunch of text (e.g. a sudo cat /var/log/messages or most > compilations) you can't really

Re: [dev] [st] Drawing optimizations

2012-01-22 Thread Peter John Hartman
On Sun, Jan 22, 2012 at 08:02:58PM +0100, Martti Kühne wrote: > On Sun, Jan 22, 2012 at 01:22:20PM -0500, Peter John Hartman wrote: > > Hi, > > > > Unfortunately, the tmux-split-pane problem still persists. The > > tmux-split-pane problem is this: if one pane in tmux is spitting > > out a bunch o

Re: [dev] [st] Drawing optimizations

2012-01-22 Thread Martti Kühne
On Sun, Jan 22, 2012 at 01:22:20PM -0500, Peter John Hartman wrote: > Hi, > > Unfortunately, the tmux-split-pane problem still persists. The > tmux-split-pane problem is this: if one pane in tmux is spitting > out a bunch of text (e.g. a sudo cat /var/log/messages or most > compilations) you can

Re: [dev] [st] Drawing optimizations

2012-01-22 Thread Peter John Hartman
On Sat, Jan 21, 2012 at 11:54:17PM +0100, Aurélien Aptel wrote: > Hi all, > > I've made st ~10x faster on my computer. If there are no major bugs I > will tag tip as version 0.2. > Here's the relevant commit message: > > * add a timeout value (SELECT_TIMEOUT) of 20ms in the select() call > * wait

Re: [dev] [st] Drawing optimizations

2012-01-22 Thread hiro
Give me a break. Our eyes need to rest, too. Stop coding everyone. (I will from now on only troll on Sundays, thanks for your patience)

Re: [dev] [st] Drawing optimizations

2012-01-21 Thread Jeremy Jackins
On Sat, Jan 21, 2012 at 3:54 PM, Aurélien Aptel wrote: > Hi all, > > I've made st ~10x faster on my computer. If there are no major bugs I > will tag tip as version 0.2. > Here's the relevant commit message: > > * add a timeout value (SELECT_TIMEOUT) of 20ms in the select() call > * wait at least

Re: [dev] [st] Drawing optimizations

2012-01-21 Thread Aurélien Aptel
Hi all, I've made st ~10x faster on my computer. If there are no major bugs I will tag tip as version 0.2. Here's the relevant commit message: * add a timeout value (SELECT_TIMEOUT) of 20ms in the select() call * wait at least 20ms (DRAW_TIMEOUT) between draw() calls * only copy dirty lines from

Re: [dev] [st] Drawing optimizations

2011-10-24 Thread Stefan Mark
On 21.10.2011 00:00, Aurélien Aptel wrote: > Hi, > > I know st rendering is slow. I'm currently trying out different > solutions but I can tell you profiling X calls is no fun. > > tip now uses a simple dirty flag per line algorithm. > Each modified line has the flag set to 1. Only dirty lines ar

Re: [dev] [st] Drawing optimizations

2011-10-20 Thread pancake
I would like to see similar optimizations in libdraw and swk. Another optimization would be to add a dirty for columns.. Or well.. For rectangles which are the damaged areas. This will require some more work in order to get a list a smallest rectangles to be redrawn. We have to find a balance b

Re: [dev] [st] Drawing optimizations

2011-10-20 Thread Peter John Hartman
> tip now uses a simple dirty flag per line algorithm. FWIW: this makes it worse in my particular test case (split-screen mutt; RHS compiling something; LHS editing a file in joe). Best, Peter -- sic dicit magister P University of Toronto / Fordham University Collins Hall B06; Office Hours TF1

[dev] [st] Drawing optimizations

2011-10-20 Thread Aurélien Aptel
Hi, I know st rendering is slow. I'm currently trying out different solutions but I can tell you profiling X calls is no fun. tip now uses a simple dirty flag per line algorithm. Each modified line has the flag set to 1. Only dirty lines are drawn and once it's done their flag is set back to 0. I