On Fri, Nov 13, 2009 at 03:26:54PM +0100, [email protected] wrote:
> then I used the attached perl extension:
> on_add_lines { $term->scr_bell if ! $term->focus &&
> $term->resource("visualBell"); }
>
> First problem I may need to desactivate it sometimes when, eg, a compilation
> happens, or when I'm on another desktop, I still have to solve that
The problem is that the bell is a one-time-event, not a state
(notwithstanding the fact that the urgency hint is a state, but there is
considerable confusion on whose job it is to clear it, and I'd rather not
touch urgency at all).
> I would also like a $term->scr_is_ringing so I can add it to the condition
I guess you would be better off to do your own handling. OTOH, I don't think
the extra bell will cause many issues.
> But here comes the question, I make some tests about performances (quite
> afraid about the on_add_lines hook) but I wasn't able to get any stable
> results between xterm, urxvt-tabbed, urxvt-notifiy display /dev/urandom or
> hex /dev/zero.
1. avoid multi-cpu setups
2. avoid realtime priorities
3. make sure you use the same font and window-size
4. try nice -n-20
5. make sure the window sare fully visible, or at least
visible the same way for all windows.
6. /dev/urandom is bad (very slow), /dev/zero is bad (too much
similar content, urxvt/rxvt optimise here).
Also, the linux kernel has a variety of bugs that rate-limit ttys -
experiment with different line-widths (more precisely, different write()
buffer lentghs in your dumping program). different line-widths will have
tremendous effect, as well as the LINUX_YIELD_HACK and kernel version
(assuming you use a linux kernel).
> Doesn't such hooks need to be conditionally unhooked at runtime (I don't
> know perl enough and it's maybe totally ingenuous), when eg, term has
> focus ?
Well, you *can* unhook them, and it will gain you performance. Best make a
few tests, the overhead is not crippling, but compared to not having the
hook, the C++ code is of course quite a bit faster.
Note that the tabbed extension never unhooks, out of lazyness, and
apparently nobody found that aspect of tabbed a problem (as opposed to
many other problems).
YMMV.
> I experience another problem : resizing a window make all tabs being rewritten
> so all terminals blink asking attention (urxvt-tabbed avoided that)
That's surprising, but you are right, the window sizes are somewhta
independent in tabbed.
I don't think you can do anything really well - the windows *do* show
activity when resized because the programs in to react to it. If you run
"cat" then you wouldn'T see such activity on resize.
Apart from evil hacks such as ignoring activity x seconds after a resize I
don't think this is solvable.
> Another question is on_add_lines brings a lot of granularity but shouldn't it
> called on_add_char and a new on_add_newline created (I'm just curious about
> performance if lines are filtered at C level even if I'm still not able to
> find
> a good test case)
Not sure I understand that - what would filtering on newlines offer you?
Also note that add_char, when called on a single char, would definitely
cause performance issues. And, newline is a char to me, too.
Greetings,
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
