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

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

On Sat, Mar 10, 2001 at 01:45:12AM -0800, James Simmons wrote:
> 
> >Well, but mostly the expensive part of it is passing from the system
> >memory to the card memory, where the bus is limiting us.
> 
> I know. That is why I'm pushing this fbcon to accel-con move.
> 
> >but you could use this 64 glyphs as a cache, or something such, uploading
> >only the most used chars or something such.
> >
> >That said, other cards can use standard FB memory for font cache, and
> >then either do a blit or a pattern expansion to the screen.
> 
> 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.

Like said before, what X is doing is :

  we have blit accel, fill accel, mono8x8 pattern fills, ColorExpand Fills,
  WriteImage and WriteBitmap. (well there are more, but these are supported by
  the glint driver).

Well, in fbdev, we already support the first two, isn't it ? for emptying
screen and scrolling, and you do a wrtieimage or something like it for drawing
fonts, but that's it.

When drawing fonts, you copy the color info to the framebuffer, but mostly
each font is one color only, so you send the same color info to each position,
err that would be the same color to each lit pixel, and the background color
to the background. It is much more efficient to set the foreground/background
color to use and then write bitmaps that will be color expanded to it, either
trough a font cache or directly.

you could then provide a write image function, but this would only be used for
writing images (like the penguin logo) or maybe colored fonts (if or when
those exists).

That said, you have to be aware, that on most hardware that have a bypass unit
(err direct framebuffer access, that is) if you don't do fancy things (like
blending and logic opps) then the direct framebuffer access may be faster than
the image write, since you have to pass the data trough the bus anyway, and it
will either be written directly to the FB, or go trough the graphic core, in
which case, you have to send additional info for the graphic core to be
configured right.

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

Err, no, you want to use the same function to do two different things :

What i would propose, but then i only know well the glint family of chips is
the following :

  * you have a function for setting the fore/background.

  * you have a function for writing bitmap to the offscreen memory.

  * you have a function for write expanding bitmaps to fore/background color
    directly from bitmap data you provide the chip.

  * you have one for doing color expansion from the offscreen memory.

Driver would provide both, or either one of them, or none, and provide a flag
telling the rest of it which one to use. Maybe be we could use a flag also to
set the relative expense of using each method, so the upper layer can choose
which one to use, depending of the font size or something such.

and writing data would be (in the direct case) :

  * set the font color. (maybe 2 register writes, one for each color).

  * while the font color does not change, just repeat :

    - expand one char at a time (usually chips can do upto 32x32 chars or
      somethign such, other may be limited to 8x8 one).

      The cost of this would be 1 32bit register per 32pixels, or 1 register
      write per line of font. You could even combine various 8 or 16 width
      fonts in one if your hardware don't support automatic
      padding/compression.

If you use font caching, you need to know what font are in the cache (using a
bitmap) if not all are, and jsut send the few register command to draw them,
or if it is not present, upload it, and then do the expansion.

This makes much more sense than a image write function that will maybe only be
used for the penguin, and may be done faster using the direct framebuffer
access, if yo don't do fancy stuff (which may not be supported anyway by the
fbdev, or used in the common layer, userland apps may do this kind of things
though.)

As for the planar hardware, i guess this is similar to just writing to one
plane, or only writing to the planes that are needed by the color selected. I
guess it is faster when using only as much colors as there are planes ?

Ok, that's all i had to say about this, but iam not really that familiar with
fbdev, and this may have been done already, or thought off and discarded. If
such is the case, plase excuse me of taking your time this way ...

Friendly,

Sven Luther