Summary: | Should the XCB backend for cairo_surface_flush() call xcb_flush()? | ||
---|---|---|---|
Product: | cairo | Reporter: | junkmailnotread |
Component: | xcb backend | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED WONTFIX | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | enhancement | ||
Priority: | medium | CC: | silverpower |
Version: | 1.6.4 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
junkmailnotread
2008-06-05 05:11:21 UTC
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. |
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.