PATCH: XGraphicsConfiguration implement font metrics cache

Scott Gilbertson scottg@mantatest.com
Fri Jan 17 15:46:00 GMT 2003


I could certainly re-address this thing when I'm not on an immediate
deadline (in a week or two, perhaps).

How about an LRU ("least recently used") buffer scheme, but no background
thread:
 - possibly one cache per display
 - each font cache entry gets a timestamp whenever it's used
 - keep track of the oldest such timestamp
 - each time a font is requested, if the oldest timestamp among the other
   fonts is over some value (1 minute maybe), kill that entry
 - possibly modify the age threshold based on the size of the cache, or
   include a hard limit on the cache size, or something like that

And if someone points out why we need it:
 - finalizing the per-display cache efficiently, details to be worked out
   if/as necessary

Oscar Pearce wrote:
> If it were me coding the cache, I would set up a cache per Display that
> got cleaned out when the Display was finalized (and/or add a dispose()
> method to Display).  I don't *think* there's a possibility of multiple
> Displays in use the way that AWT is implemented, but it would be safer.
>
> The never-shrinking cache bothers me, too, especially since a Font
> represents a server-side resource.  I'd limit the size of the cache to
> some fixed number of entries, but I don't have a good feel for if that
> number should be 1, 10, 100, or 1000.  (Actually, if I expected to use
> this real heavily, I'd go to the trouble of having a cache that a
> background thread checked every once in a while to see if it throw some
> Fonts away when they hadn't been used in a minute or so.  But I suspect
> that's way overkill for the amount of use that these classes are going
> to see.)
>
> Just my two cents,
> Oscar
>
> On Thu, 2003-01-16 at 14:34, Scott Gilbertson wrote:
> > I came accross a comment that said "FIXME: do caching", so I did.  I see
a
> > couple of possible problems with this patch, though:
> >  1. it assumes that visual.getScreen().getDisplay() always returns the
same
> > value
> >  2. if you use many different fonts, the cache will just keep growing
> > My guess is that #1 is a valid assumption.  Regarding #2, I considered
using
> > weak references, but that would risk having fonts taken out of the cache
> > immediately before they're needed again, so I decided against it.
> >
> > To test it, I ran my application which uses Graphics.setFont in a lot of
the
> > paint functions, and confirmed that a few different fonts show up
properly.
> > I also noticed a large speed improvement when painting a lot of text
fields.
>
>




More information about the Java-patches mailing list