GNOME Bugzilla – Bug 628291
Drawing artifacts when used with a cairo 1.9.*
Last modified: 2010-09-12 09:51:51 UTC
When using the latest Gtk+ 2.21.6 with the latest Cairo 1.9.14 snapshot some rendering is incorrect. It is mainly with cellrenderers and the button mouseovers. This is on Windows using the Murrine theme engine. On Windows using the default engine or on Linux with Murrine everything looks OK. I traced it back to this Cairo commit http://cgit.freedesktop.org/cairo/commit/?id=4438cc6a49e7e902dce045706f7125a2c3e2174b This means quite a change in semantics for cairo_destroy which obviously impacts the Cairo/native interaction.
Don't use the Murrine theme engine then? My personal opinion is that the only theme engine worth even trying to support for GTK+ on Windows is the MS-Windows one. Even that is hard enough, as has been seen.
Created attachment 169037 [details] [review] proposed patch This patch fixes the problem. It is based on the gtk-2-22 branch. I don't know whether it is applicable to master too.
(In reply to comment #1) > Don't use the Murrine theme engine then? My personal opinion is that the only > theme engine worth even trying to support for GTK+ on Windows is the MS-Windows > one. Even that is hard enough, as has been seen. Murrine has been working very good on Windows for me. Moreover, I think that the patch is correct and an improvement for every platform, even though only the particular combination of Windows+Murrine exhibits the defects.
Created attachment 169201 [details] [review] gdk: Ensure flush of surface when cairo_t is destroyed Add an ugly workaround because GTK does not ensure surfaces get flushed before directly accessing the drawable backed by the surface. This is not visible on X11 (where flushing is a no-op), but can be seen on Windows.
(In reply to comment #4) > Created an attachment (id=169201) [details] [review] > gdk: Ensure flush of surface when cairo_t is destroyed That patch also solves the problem. I'm not sure why it is better then my patch, but my main concern is that one of the patches gets in git in time for the 2.22 release.
I suppose my patch is preferrable becaues it only changes one place and because it works for all the other places where you didn't cairo_surface_flush() after a cairo_destroy() yet. ;)
Is it possible to land one of the patches in time for the 2.22 release? (I do not have commit access)
Pushed to 2.22 branch, but not master.
Could this be cherry-picked to gtk-2-20, too?
Sure. It's pretty much a no-op on anything but win32, so go ahead.