[cairo] changed semantics of cairo_destroy

[Maarten Bosmans]

2010/8/31 Benjamin Otte <otte at redhat.com>:
> It's interesting that the win32 surface works as well as it does,
> because Gtk 2.x interchangably renders using Cairo and native calls all
> the time. So creating a cairo_t, rendering to it, then switching to
> direct rendering using GdkGC, then continuing to render to the cairo_t
> is the normal way of doing things.
> So a surface flush only in destroy() will not help things.

Well, it certainly solved the rendering artifacts I was seeing. But
indeed, it is quite a mess and it works better then can be expected.

> Or in other words: If the X11 backend would do flushing, all programs
> would be broken right now and the disro maintainers would hunt you with
> pitchforks...

Do you mean that my proposed patch for Gtk would break X11 apps? Or
just that it would cause problems if Gtk on X11 would be as strict as
on win32?

> Note that GTK 3 will not have these issues, because all drawing is done
> using Cairo.

Yeah, great work you're doing there!

> Just adding surface flushes in random places is not going to help at
> all, because all the other places that interchangably render with GCs
> and cairo_t will still not work. You could try adding a surface_flush()
> after every cairo_destroy() in GTK and hope for the best, but you'd have
> to do that everywhere, including the murrine engine.

Indeed, I first started adding flushes to murrine, but it didn't solve
the problem as those cairo_t where all shortlived and were not mixed
with native rendering. The flushes in the patch were the minimum
required to get correct rendering on windows, but that's not to say
that there shouldn't be more to be really adhering to the cairo/native
semantics.

> Finally, I'd like to point out that the fault certainly lies with GTK,
> it should have done those flushes all the time. But the fact that Cairo
> didn't enforce them (in particular on X11) caused this to not happen...
>
> Benjamin

Maarten