freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Caching freetype bitmaps...


From: Pedriana, Paul
Subject: RE: Caching freetype bitmaps...
Date: Thu, 22 Jun 2000 12:49:16 -0700

   >>I'm already caching glyph sizes - not sure 
   >>if caching the pre-drawn bitmaps is a great 
   >>idea compared to using GlyphSlots...

Caching pre-drawn bitmaps *is* a good idea when the format
of the bitmaps is as an OpenGL or Direct3D texture. This 
is what we're doing. Note the domain of my email address
to make sense of why we're doing it.

Paul





-----Original Message-----
From: Elliot Lee [mailto:address@hidden
Sent: Thursday, June 22, 2000 12:41 PM
To: address@hidden
Subject: RE: A couple of issues with freetype2-beta6


On Thu, 22 Jun 2000, Pedriana, Paul wrote:

>    >>I'm not asking for caching, just an API that 
>    >>allows implementing it. If I can specify GlyphSlot 
>    >>to load a Glyph into, that's all I need.
> 
> Since when doesn't the current design allow for caching?

API, not design. AFAICS the best way to implement caching is by having a
bunch of GlyphSlot's around, but I can't do that if there's no way to get
a Glyph into more than one GlyphSlot using the existing API, even if the
design does allow to implement it eventually.

> What I do is create a C++ STL map of glyphs to cached glyph
> information. New entries are loaded on demand and entries can be
> purged via a simple LRU (last recently used) algorithm.  Thus, when a
> string of text needs to be drawn, each character is looked up in the
> set and all the information, including a pre-drawn version of the
> character, is there to simply blit.

I'm already caching glyph sizes - not sure if caching the pre-drawn
bitmaps is a great idea compared to using GlyphSlots, but it's a "duh" I
should have implemented in the meantime.

-- Elliot
The best way to accelerate a Macintosh is at 9.8 meters per second per
second.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]