Re: scrolling optimization + asynchronous updates impossible

[Marcus Brinkmann]

On Fri, Jun 14, 2002 at 06:14:06PM -0400, Roland McGrath wrote:
> Some things might use the vt100 scrolling region, which behaves like an
> atomic delete+insert line.

Sure, there are some such escape sequences, and they might even be used, in
particular in programs like text editors.  However, as I found out that even
in polling mode you can get quite good results by polling the whole screen
every 10ms, I hope it is not a big deal if we poll half a screen for a line
insertion.  I think details like this can only be fine tuned after using
the console with as many programs as possible, and check where the problems
arise.

> File change notifications are always delivered asynchronously.

Actually, fs_notify.defs is using routines, not simpleroutines, and we have
special hacks in libdiskfs and console to get simpleroutines... delivering
them synchronously would work as well, although it would not be so good if
you have multiple clients.

BTW, if the port queue is full, the call blocks in the server, even if it is
a simple routine, because the MiG stubs don't have a timeout (or notify
port).  I just tried it: Using ports_manage...one_thread, the server will
block during operation, and the effect is that we have almost synchronizity
where the server is always a couple RPCs ahead (as many as the queue can
hold).  In the case of several clients, this would block other clients, too.

When I implement a scheme like Nils suggested, we can get full
asynchronicity.  But I will punt this for later, as it is not necessary to
get a functional and usable program, and it has other problems, so this will
require a functional base so we can make tests with real applications to see
what effect those changes will have.

> I think this points to the fundamental overhead of your current console
> design.  The functional splits make sense, but one way or another flicker
> just seems real likely.  

I am not so sure.  Of course we can only tell when it is ready, and so far I
am mostly looking at what happens with programs like find, not emacs.  For
terminal scrolling like it is needed for find, I think we can get a decent
behaviour, because I can first change the invisible "soon to become visible"
area and then sent the RPC that shifts the visible area down to cover this
new bottom area.  For programs like emacs, if they do use line
insertion/deletion capabilities, we will have to see what happens.
As I am coding, I find little things to fine tune the behaviour here and
there, which can have a dramatic effect on performance.

Apropos performance.  We already win here, even over the Mach kernel
console.  Here is a comparison for "find /share"

to /dev/null:    0m 18s
to Mach console: 1m 46s
to screen vt:    1m 49s
to my console with the curses client running, on top of the Mach console:
                 1m 35s
my console server without client:
                 0m 34s (or so)

Note that the 1m 35s includes conversion to and from Unicode, and all the
ncurses stuff, and of course also utilizes the Mach console evenually, and
it is still faster.  Don't ask me why, must be the processing in large
chunks rather than individual characters.

When my curses client runs within screen, the time is much worse, 2m 24s.
I forgot the time for my console server without client attached, I
think it was a bit less than 1m.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de