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

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

On Wed, Mar 07, 2001 at 02:53:17AM -0800, James Simmons wrote:
> 
> >I was wondering if it could be worthwhile (speedwise) to implement
> >a fonctcache for fast character display.
> 
> If you think about it we already have something like that with teh current
> system execpt instead of it being in card memory it is in system memory.
> Using a image blitter you can translate that data from normal RAM to the

Well, but mostly the expensive part of it is passing from the system memory to
the card memory, where the bus is limiting us.

> video card memory. The nice thing about a image blitter is you can do
> depth translations (mono to depth X). I though about using a Glyhp
> approach. The voodoo 3 card has a pattern buffer for up to 64 Glyphs which
> can then be very quickly painted on the display. The problem is the
> console system supports alot more characters than that. In the future I
> hope even more.

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 satndard FB memory for font cache, and then
either do a blit or a pattern expansion to the screen.

That's how X does it at least.
> >fbcon_cfbXX_putc() in ofscreen memory once per character (on-
> >demand, likely), and just _bmove() them to proper place.
> >
> >On the pm3, that would cost 4 memory access to the registers
> >(in PCI memory space) (6 if not properly aligned, for the
> >scissors stuff) plus the hardware copy, compared to whatever
> >fbcon_cfbXX_putc() use.
> >
> >Would that be worth the hassle of adding the fontcache ?
> >(I have no idea what putc() actually cost).
> >
> >Would that be worth adding a more generalized implemetation
> >on top of existing _bmove() so that every hardware-accelerated
> >board could use it ? (those without HW-accel putc(), that is)
> >
> >Is that already planned for the 2.5.x API ? (haven't seen
> >anything to that extent in 'ruby' but I might have
> >overlooked something)
> 
> Yes. This is the way the ruby tree handles it. I just got it working in
> the ruby tree. The only problem is their is some bug in take_over_console
> I have to chase down but I do have fbcon running using a voodoo 3 along
> side my MDA. There are 3 functions. One is rectfill which does things like
> clear the margins etc. Then their is fb_copyarea which copys a area of the
> screen to another area of the screen. The last function is fb_imageblit
> which transfers data from host memory to screen memory. This is used to
> draw the penguin and text. Yes it is simpler to use the accel engine. A
> good example is the new tdfx driver in the ruby CVS.

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.

Friendly,

Sven Luther