Re: console update

[Stephan Trebels]

Why you didn't create separate matrixes for attr, 1st char, second
char, or for simplicity mandatory vs. optional matrixes.

I agree, it'd look weird, but it'd remove the interleave problem
immediately.  And you can support a huge cellsize without ever
comitting the memory unless it's used.

Just curious, Stephan

> The question is, what information should this matrix cells hold?
> This is what we have now:
> 
> Bytes relative to &_matrix[0], type, meaning:
> 0-3   wchar_t         Unicode character in row 0, col 0.
> 4-7   conchar_attr_t  Video attributes for character in row 0, col 0.
> 8-11  wchar_t         Unicode character in row 0, col 1.
> 12-15 conchar_attr_t  Video attributes for character in row 0, col 1.
> ...
> 
> Note that the cells include the scrollback buffer, and that the actual
> visible area can start in any row in the matrix.
> 
> This obviously limits us to Unicode support level 1.  Increasing the
> number of wchar_t's for each cell would allow us to support compose
> characters at least in the console server (passing them through to the
> client).  However, this increases the memory footprint enormously.
> For example, if you have a scrollback buffer of 500 lines, you have
> 500*80 = 40000 character cells.  If you support what ncurses supports,
> that is up to five characters per cell, you have 24 bytes per cell
> (5*sizeof(wchar_t) + sizeof(conschar_attr_t).  This is 937kb of data!
> With 10 virtual consoles, this adds up to 9 MB of data, most of which is
> unused.  As the common case is that only three bytes of the 24 are
> actually relevant (two attribute bytes and one character byte) for
> isolat1 characters, you have 21 wasted bytes per cell (an efficiency
> of 14 percent), and what is worse, they are all interleaved with the
> real data, so you touch all pages.
> 
> > I think it should send actual Unicode; and the lower-level is
> > responsible for composing the character.
> 
> We do send unicode, but we don't send anything that can be composed, as
> composing is not part of unicode support level 1 with NFC.  I think it
> is a good idea to see what other folks who seriously work in this area
> (usually for the Linux kernel) cook up before putting work into more unicode
> support.  When we get unicode support level 1 and NFC, we will have
> made a jump ahead that applications first need to reach anyway (not all
> applications are ready yet for UTF-8).
> 
> Thanks,
> Marcus
> 
> 
> _______________________________________________
> Bug-hurd mailing list
> Bug-hurd@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-hurd

-- 
           Stephan Trebels <stephan@ncube.de>, Consultant
mail: nCUBE Deutschland GmbH, Hanauer Str. 56, 80992 Munich, Germany
phone: +49 89 149893 0  cell: +49 172 8433111  fax: +49 89 149893 50