Should the XCB backend for cairo_surface_flush() call xcb_flush()? If I call cairo_paint() on an XCB backend, the source image will not be displayed on the screen until I call xcb_flush(). For reasons of portability - at some point I want to switch to Glitz - I would prefer to call cairo_surface_flush() instead of xcb_flush(). However cairo_surface_flush() has no effect because the XCB backend flush function is NULL. The description for cairo_surface_flush() says "Do any pending drawing for the surface ...". To my mind that justifies calling xcb_flush(), since otherwise no drawing takes place. However the description also says "If the surface doesn't support direct access, then this function does nothing." I must admit I'm not sure what that means; perhaps it explains why xcb_flush() is not called.
No it shouldn't. We made xlib_flush do that, and it was a disaster. What the surface_flush() means is that cairo flushes all its internal state out. So in your case, it's now living in xcb connection cache. I have proposed in the past to make cairo_surface_show_page() do the xlib/xcb_flush in the past. Still think that's a useful feature.
cairo_surface_flush() only guarantees that all operations are complete before you try to read back from the surface. X enforces that all outstanding operations are complete before a XGetImage() reads back from the surface. The remaining issue would then be somebody mixing direct pixel manipulation with XRender to a ShmPixmap and that would require cairo_surface_flush() to call XSync()! And if XFlush() was a performance disaster... However, cairo_surface_show_page() calling XFlush() has merit and would seem to fit the sematics, so copying to TODO.
*** Bug 16031 has been marked as a duplicate of this bug. ***
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.