Re: Video subsystem draft

["Yoshinori K. Okuji" <okuji@enbug.org>]

On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote:
> > 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.

I must test it myself, too. The performance of reading a compressed file is 
slow, because of seeking. Seeking forward is fast, but seeking backward is 
very slow. So compression makes sense for OS images, but not much for font 
files.

The most important part is the initial cost, BTW. Since a boot loader must be 
quick to start up (otherwise, the user loses some seconds every time), 
caching is not so important.

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

Yes.

> 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.

I see.

Okuji