On 30 May 2001, Juliusz Chroboczek wrote:
> > 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.
It's quite possible, I've been battling to get good performance under
'doze recently.
> (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.)
STOP right there.
I do NOT mean a shadow _bitmapped_ frame buffer, that's an evil tradeoff
that would probably be reversed by using an acclerated graphics card or
any form of network link. (If I'm being 'doze-centric I'd say terminal
server or Cytrix)
I mean you detach the updating of your in memory _character_ buffer from
the painting of those characters onto the bitmapped screen.
That way if the emulator ever gets stressed it only has to do character
maipulation with a very rare screen update (every 1/20 second say) and
even under normal use it reduces the network (graphic blitting) load
it generates by only updating the screen once every packet of characters.
> 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.
A backlog would be rare, but it only happens if the emulator is stressed.
(ie exactly when it needs to be optimised :-) )
A large(ish) packet is much more likely because of Mr Nagle.
It also makes the emacs style screen updates look better 'cause it appears
to happen instantly rather than the bottom of the text wizzing up the
screen then back down again before the bit in the middle is painted in,
tho I think that was only really relevent below 50Mhz.
--
Rob. (Robert de Bath <rdebath @ poboxes.com>)
<http://www.cix.co.uk/~mayday>
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
