Re: Video subsystem draft

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Tuesday 22 November 2005 08:06 pm, Vesa Jääskeläinen wrote:
>> I think it can be gzipped to fit more nicely :).. (and it seems to work
>> too).
> 
> Compression might make the performance horrible, because PPF is very 
> optimized.

When there is a caching implemented in a one day, it's only initial
cost. So far I haven't seen performance problems with this. But then
again I haven't tried it too much.

>> After something calls grub_error first read from font file fails, with
>> grub_file_read() == -1. Now this causes font manager to drop font from
>> memory. If I disable feature that I can see that first character is
>> invalid and others come nicely. In case of "error: ..." first 'e' is
>> corrupt and rest is ok. I am not sure is this really issue in grub_error
>>  itself but it is in sequence when problem shows up.
>>
>> I can't find problem in font manager, even the offset that is tries to
>> seek is within limits of the file (and correct) and there is enough
>> bytes left in file in order to successfully complete the read.
>>
>> I can send tarred version of grub2 with video subsystem if someone wants
>> to help on this one. I will continue to search for possible problems in
>> case I can pinpoint and fix it.
> 
> I will check this myself later.

Just in case you (or someone else) want to test current version, I have
uploaded it to:
http://jumi.lut.fi/~vjaaskel/grub2/grub2-video-20051126.tar.gz

I noticed that when ever I call grub_error something brakes, but what is
doing it I can't tell. There is a testerr3 function in video/video.c
that tries to demonstrate when does the corruption occur.

Oh.. and before anyone asks, video implementation is not still complete.
Code itself probably wont compile in other archs. But I think the
interface itself could be OK. But it needs to mature a bit. VGA module
is disabled until I have time to look how to modify it to fit new system.

>> Is the font file using some standard format or can it's contents be
>> changed? Bitmap data for fonts could be placed in better order to more
>> easily to render it (currently I modify byte order before giving it to
>> glyph renderer). (My guess is that it is [P]upa [F]ont [F]ormat or file)
> 
> If you want to improve it, feel free to do it. It is our own format. But I 
> think the byte order was set conveniently.

Byte order is currently exactly the same as in .hex file :)

It has minor issue with widechar fonts (char width > 1). It like
contains two different font data. First there is first half of like
normal 8x16 font and then there is second half. My idea would be to
store bitmap in scanlines instead of character blocks so I can take
whole character width and draw that.

Now I need to sleep... I will continue my tracking later one.