Re: [Linux-fbdev-devel] Re: [linux-fbdev] Is a FontCache worth implementing ?

[Sven L. <lu...@dp...>]

On Sun, Mar 11, 2001 at 09:15:43PM +0100, Geert Uytterhoeven wrote:
> On Sat, 10 Mar 2001, James Simmons wrote:
> > True. You could do this for cards that have the avaliable memory. If fbcon
> > is running at a resolution that occupies the entire memory then you are in
> > trouble. You can do many fancy tricks. I leave it up to the driver writer
> > to be fancy. The goal is to draw some image. Keep in mind I wanted to also
> > want to have the function draw the penguin. It is very miss leading the
> > name of the function. It should be drawimage instead. Also for cards that
> > lack this function a software emulated drawimage has to be done. Could
> > people post all the possible ways a "fontcache" could work. I see
> > imagedraw is going to the touchy one.
> > 
> > >What about pattern fills ? Where you provide a bitmap, and the accel
> > >engine copies this bitmap, putting 1 color for the 1s and another (or
> > >transparent) for 0s.
> > 
> > Same thing. The goal of the function is to draw some image. How it is
> > implemented is up to the driver. Another way to do it is make textures of
> > fonts and using texture mapping to draw the characters. I seen something
> > like this used for a X server before. The windowing was done with the z
> > buffer which was used to act like hardware window IDs. Each window then
> > was textured mapped with whatever the program was trying to display. The
> > texture map changed when needed. X term wa steh trickiest. Alot of little
> > texture maps but it still was fast.
> 
> With a font cache you store all fonts in an off-screen area of graphics memory,
> and let the graphics acceleration engine do monochrome-to-color expansion for
> each individual character.
> 
> For systems that don't have hardware acceleration for monochrome-to-color
> expansion and that have bitplanes (the Amiga comes to mind :-), it's much
> faster to not draw individual characters at the monochrome-to-color expansion
> level, but to prepare a bitmap for a bunch of characters and let that expand by
> software (using 32-bit accesses instead of 8-bit accesses for individual
> characters).
> 
> So here we have a trade-off: do we want to draw individual character bitmaps
> (possibly hardware accelerated), or do we glue individual characters together
> and draw the composite bitmap?

Why not provide both, and have the driver tell the rest of the stuff which way
he prefers to do it via a flag or somethign such ?

This way we can best support a wider array of hardware kind.

(but then i may be influenced by my Xfree86 experience, and don't have the
long range fbdev vision in mind a lot right now ...)

Friendly,

Sven Luther