While debugging GTK+-Quartz it appeared that on several occasions a call to cairo_destroy() is mandatory for the drawing to be done correctly. Omission of a cairo_destroy() call can lead to the results of later cairo drawing calls to not appear on the screen. I have been told that a call cairo_destroy() should not be mandatory and that there are likely flags that are not being properly reset.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.