[cairo] Hash rewrite #3: cairo_scaled_font_map

[Keith Packard]

On Fri, 2005-08-12 at 23:38 -0700, Carl Worth wrote:

> Is setting the translation elements to zero the correct thing to do?
> If the intention is to ignore the translation elements, then I agree
> they should be cleared and hashed. But from a quick glance, (including
> the documentation of cairo_set_font_size and cairo_set_font_matrix), I
> don't see anything that explicitly says the translation elements are
> ignored. Owen?

hmm. I can see uses for translations in the font matrix, including
constructing artificial super- and sub- scripts.

The postscrip document that I have doesn't mention the translation
elements of the matrix in the makefont operator documentation, and the
examples are presented with no translation component.

I tried to write a bit of PostScript to test whether the translation has
any effect, but my ghostscript installation is fubar today and I
couldn't get any transformed text to display at all.

I'd say we should do what PostScript does with the translate element.

> > Similarly, should we just memcmp the whole key? I don't see any pointers
> > in it. Or are you concerned about padding in the options structure?
> 
> One difficulty (again) is that we don't have a separate structure for
> just the key anymore. Perhaps that's a defect in the new model, but
> I've been claiming it as a feature since you no longer need a mostly
> redundant structure just to act as a key. But perhaps it would make
> sense to embed a key structure within the value to make it more clear
> which fields are part of the key, (and then the memcmp thing could be
> done).

I think that would be a helpful convention -- make the key a
substructure within the value. We might, then, also be able to
distinguish between filling in a key for lookup purposes and
constructing a complete value, which would make me happier with the
inconsistent memory ownership situation of the current hash code.

> > +    /* If the original reference count is 0, then this font must have
> > +     * been found in font_map->holdovers, (which means this caching is
> > +     * actually working). So now we remove it from the holdovers
> > +     * array. */
> > 
> > Could the removal of this element from the holdover array occur a bit
> > closer to the code which locates it there? This kind of 'reference == 0'
> > magic seems fragile to me.
> 
> I don't see any good way to change that. We never look in the holdover
> array for anything. The holdovers get picked up through normal hash
> lookups.

Oh, right, the holdovers are just located by hash lookups and have
reference zero which lets us know to remove them from the array when
used by the application again. I can't think of a sensible way to change
this.

I did have a question about the fixed size of the holdover array. I'm
imagining roadster will use far more than 24 distinct orientations of
the font, which will run right over this cache, but each use will
generate only a very few glyphs.

A scaled font instance is really nothing more than the collection of
metrics and images for each glyph, so in some sense we should ignore the
number of scaled fonts and concentrate instead on the total memory used
by the application for glyphs. Include the holdover in this computation
and let the list of held-over fonts expand to capture the set of scaled
fonts which cover the working set of glyphs used by the application.

As we know which scaled fonts have been recently used, we can then
simply purge glyphs from older fonts to keep total memory usage under a
specified limit. Once a scaled font has no glyphs associated with it, we
could remove it from the system.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050813/2e6ff163/attachment.pgp