[cairo] invalid size error, nth ping
Behdad Esfahbod
behdad at behdad.org
Mon Jan 19 23:42:23 PST 2009
Paolo Bonzini wrote:
> AUTO is not "whether" to cache (the full name is
> CAIRO_CACHE_ENABLE_AUTO, so the cache is enabled), but "how".
>
> The policy defines what to do with dirty cached data. MANUAL (use dirty
> data unless explicitly flushed) was only for backwards-compatibility
> with the Quartz image surface, because that's what it implemented.
We don't care about compatibility with Quartz image surface.
> AUTO
> and DISCARD make a difference only if >1 cached representations are
> there, say Quartz and Glitz: if they are dirty and the Glitz backend
> requires its representation, DISCARD throws away the Quartz
> representation, while AUTO asks the Quartz backend what to do.
This all can and should be automatic.
> If you decide only one (probably AUTO) is needed, I can remove the other
> one and just have CAIRO_CACHE_{DISABLE,ENABLE}.
The question is whether we even need that. I'm not convinced that we do.
>> 1) For image surfaces we know if the user has direct access to the data.
>> 2) Technically users are supposed to call cairo_surface_mark_dirty if they
>> modify it. No one does now of course because that call's pretty much a nop.
>
> Oh, that's good news. On the other hand the chance of bugs is high,
> because mark_dirty_rectangle is only implemented by the OS/2 surface
> now. So I'm not sure that it means we can start caching stuff
> automatically, especially if the widely used Xlib surface starts using
> the cache (e.g. for Xshm).
Bugs can be fixed.
> One alternative could be to add optional caching in 1.10 with a big
> warning on the release notes, and add heuristics in 1.12. Either
> approach has its drawbacks of course. Even if heuristics are to be
> added in 1.10, it can be done on top of the patches in the branch (i.e.
> I won't disappear).
No API additions unless someone really shows that we need it. With numbers
and all.
behdad
More information about the cairo
mailing list