summaryrefslogtreecommitdiff
path: root/gdk/gdkwindowimpl.h
diff options
context:
space:
mode:
authorJasper St. Pierre <jstpierre@mecheye.net>2014-06-20 11:55:09 -0400
committerJasper St. Pierre <jstpierre@mecheye.net>2014-06-20 20:41:54 -0400
commitd48adf9cee7e340acd7f8b9a5f9716695352b848 (patch)
treeff5863310c663a9971d7fed9fec4b739a9215a75 /gdk/gdkwindowimpl.h
parentb875572f2af532b0e8f2dc368f8dc824b5f92724 (diff)
downloadgtk+-d48adf9cee7e340acd7f8b9a5f9716695352b848.tar.gz
gdkwindow: Remove the internal cairo_surface used for out-of-band painting
Traditionally, the way painting was done in GTK+ was with the "expose-event" handler, where you'd use GDK methods to do drawing on your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create, so you could paint your graphics with cairo. Since then, we've added client-side windows, double buffering, the paint clock, and various other enhancements, and the modern way to do drawing is to connect to the "draw" signal on GtkWidget, which hands you a cairo_t. To do double-buffering, the cairo_t we hand you is actually on a secret surface, not the actual backing store of the window, and when the draw handler completes we blit it into the main backing store atomically. The code to do this is with the APIs gdk_window_begin_paint_region, which creates the temporary surface, and gdk_window_end_paint which blits it back into the backing store. GTK+'s implementation of the "draw" signal uses these APIs. We've always sort-of supported people calling gdk_cairo_create "outside" of a begin_paint / end_paint like old times, but then you're not getting the benefit of double-buffering, and it's harder for GDK to optimize. Additionally, newer backends like Mir and Wayland can't actually support this model, since they're based on double-buffering and swapping buffers at various points in time. If we hand you a random cairo_t, we have no idea when is a good time to swap. Remove support for this. This is technically a GDK API break: a warning is added in cases where gdk_cairo_create is called outside of a paint cycle, and the returned surface is a dummy that won't ever be composited back onto the main surface. Testing with complex applications like Ardour didn't produce any warnings.
Diffstat (limited to 'gdk/gdkwindowimpl.h')
-rw-r--r--gdk/gdkwindowimpl.h9
1 files changed, 0 insertions, 9 deletions
diff --git a/gdk/gdkwindowimpl.h b/gdk/gdkwindowimpl.h
index b1e9290bc1..694a244761 100644
--- a/gdk/gdkwindowimpl.h
+++ b/gdk/gdkwindowimpl.h
@@ -158,15 +158,6 @@ struct _GdkWindowImplClass
*/
void (*destroy_foreign) (GdkWindow *window);
- /* Resizes @surface to a new size. If successful, return %TRUE.
- * If the backend cannot resize surfaces, return %FALSE and a new
- * surface will be created instead.
- */
- gboolean (* resize_cairo_surface) (GdkWindow *window,
- cairo_surface_t *surface,
- gint width,
- gint height);
-
/* optional */
gboolean (* beep) (GdkWindow *window);