[cairo] Static caches and thread-safety
Bill Spitzak
spitzak at d2.com
Fri Nov 12 11:15:09 PST 2004
On Thursday 11 November 2004 07:09 pm, Carl Worth wrote:
> I'm half tempted to move the caches down into cairo_t and encourage
> users to clone from a single call to cairo_create if they want to get
> all the sharing benefits...
>
> Keeping locking out of cairo definitely seems appealing. And I wouldn't
> guess that it would be common for less-informed users to want to make
> lots of simultaneous cairo_t objects. Stupid?
>
> Thread-local storage?
>
> Nothing seems perfectly clean here. Dirty, dirty...
It seems to me that if a cache is useful, it should be shared amoung
everything and thus there is exactly one cache. Even if different things are
needed in the cache for different surfaces, a hash lookup that includes the
surface-id would be more efficient than havng a per-surface cache.
The interface to a cache may be something like this, notice that there is no
"which cache" argument because it assummes there is only one cache. However
the cairo_t argument could be used to implement multiple caches if necessary:
_Font* font = _get_font(cairo_t, stuff...);
_Image* image = _get_glyph_image(cairo_t, font, data);
draw_the(image);
_release_glyph_image(cairo_t, image);
_release_font(cairo_t, font);
The idea is to provide a call to the cache that indicates when you are done
with an object, so it can be unlocked. _release_glyph_image indicates that
the image can be thrown out of the cache. This can be a no-op if the cache
never actually throws anything away, or if _release_font is the actual call
that gets things out of the cache. These should be inline macros/functions so
that they can be fast if they are trivial. Since this interface is entirely
internal using macros is no problem.
More information about the cairo
mailing list