Bug 29296

cairo_flush()?

Basically, I was talking about this with Benjamin Otte the other day, and the point is that cairo_destroy() should not introduce drawing artifacts when forgotten.  I will update the title to better reflect this.

I need some additional information about the problem you're seeing (a test case reproducing the problem would be great).

We need a testcase that reproduces the problem. As I don't have an OS X computer, I cannot do one, but I suspect that something like:

cr = cairo_create (quartz_surface);
cairo_set_source_rgb (cr, 1, 0, 0);
cairo_rectangle (cr, 0, 0, 10, 10);
cairo_clip (cr);
cairo_paint (cr);

cr2 = cairo_create (quartz_surface);
cairo_set_source_rgb (cr2, 0, 1, 0);
cairo_rectangle (cr2, 20, 20, 10, 10);
cairo_clip (cr2);
cairo_paint (cr2);

would reproduce the problem. Or maybe:

cr = cairo_create (quartz_surface);
cr2 = cairo_create (quartz_surface);
cairo_set_source_rgb (cr, 1, 0, 0);
cairo_set_source_rgb (cr2, 0, 1, 0);
cairo_rectangle (cr, 0, 0, 10, 10);
cairo_rectangle (cr2, 20, 20, 10, 10);
cairo_clip (cr);
cairo_clip (cr2);
cairo_paint (cr);
cairo_paint (cr2);

Created attachment 37664 [details]
Wannabe testcase

This is a testcase wrapping up Benjamin's code snippets in a "working" appication.

Created attachment 37665 [details]
Image produced by the testcase

The image produced by either code snippet is the same (and exactly the expected output).
I assume that some more complicated multiple cairo_t usage is required to trigger the bug.

Actually cairo_surface_flush(). The decision was made long ago that cairo
should not flush more than is required for its own correct behaviour.
cairo_destroy() is one such point where cairo can not correctly guess the
user's intention and should not flush by itself but leaves it up to the
user to choose the correct point at which to do so (because it more or
less depends upon the interaction with the rest of the windowing system
integration).

I don't have a testcase off head -- I guess we can create something by tracing the cairo calls GTK+ is making ...  Would likely be the most efficient, since I do not have an idea yet what exact pattern is causing this behavior.

(In reply to comment #8)
> I don't have a testcase off head -- I guess we can create something by tracing
> the cairo calls GTK+ is making ...  Would likely be the most efficient, since I
> do not have an idea yet what exact pattern is causing this behavior.

Did you manage to create a trace reproducing the wrong behavior?

(In reply to comment #9)
> (In reply to comment #8)
> > I don't have a testcase off head -- I guess we can create something by tracing
> > the cairo calls GTK+ is making ...  Would likely be the most efficient, since I
> > do not have an idea yet what exact pattern is causing this behavior.
> 
> Did you manage to create a trace reproducing the wrong behavior?

Andrea, I've never found the time to hash out a small, working testcase for this, sorry for that.  Ever since we've added the missing calls to cairo_destroy() in GTK+, we've no longer stumbled upon this issue.  For me, this bug can be closed.