[cairo] invalid size error, nth ping

[Behdad Esfahbod]

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