PATCH: XGraphicsConfiguration implement font metrics cache

[Oscar Pearce]

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.