My motivation here is that XCopyArea does what I want for simple self copies, but XRenderComposite does not (at least not in all situations). Also, even though I don't know why render should be slower than core, we seem to get reports that it sometimes is, so there may be a performance benefit on systems with some (buggy?) drivers. XCopyArea is used for CONTENT_COLOR surfaces so it seems that it should also be used for COLOR_ALPHA surfaces. I'll attach a patch shortly.
Created attachment 37387 [details] [review] use XCopyArea for operator SOURCE with compatible COLOR_ALPHA surfaces _operator_needs_alpha_composite was changed to take two _has_alpha arguments instead of one (and started returning false for SOURCE) in http://cgit.freedesktop.org/cairo/commit/?id=c25992479aca481d326f72665ebdcf0904273eac The call added to _cairo_xlib_surface_composite in that changeset has since been removed so _operator_needs_alpha_composite is now only used when the source and destination have the same format. I would have used a switch statement but -Wswitch-enum doesn't like "default:". I'm getting failures with svg12 outputting clear (blank) surfaces, but I haven't marked them xfail because I'm getting a large number unexpected fails for svg12 in other tests also. I haven't run the test against win32 or quartz backends, but I expect it to pass because, with Firefox, we only got reports of self-copy bugs on X11.
With my driver author's hat on, this patch should not be necessary. Humph.
Ok, cairo-1.12 should use the simpler XCopyArea for compatible surfaces and SOURCE (or reduced OVER) operators. However, I see you have a test case as well, so I may as well add that to the repository.
Principal bug should be fixed, excluding !owns_pixmap. :(
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.