> I think this is a bad idea. When the terminal emulator receives WO2,
> it needs to display a double-width glyph after it has already
> displayed a single-width one, which will complicate the implementation
> and cause flicker.
RB> Actually that's probably not true.
RB> Assuming you're writing to a bitmapped screen you should have a seperate
RB> text buffer and be using a lazy algorithm to update the bitmap. So the
RB> narrow character won't even make it to the frame buffer.
Is it me, or are you being somewhat Windows-centric? Performance
tradeoffs are very different under X11.
In the case in which characters are processed as fast as they arrive
(i.e. there is no backlog of unprocessed characters on input), XTerm
will send an update request to the X server as soon as a new character
arrives. Having SCW *after* the base character will cause two update
requests to be sent.
(It is the X server's responsibility to do the actual update; depen-
ding on the hardware configuration, this will cause a hardware-accele-
rated update to happen, or will indeed involve a shadow framebuffer as
you suggest.)
I am not quite certain of what happens if there is a backlog of unpro-
cessed characters on input. I'm not sure it's worthwile to optimise
for that case.
Juliusz
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
