After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766675 - Add appropriate frame drawing API to GdkWindow
Add appropriate frame drawing API to GdkWindow
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-05-19 16:46 UTC by Emmanuele Bassi (:ebassi)
Modified: 2016-06-09 19:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add frame drawing API to GdkWindow (21.47 KB, patch)
2016-05-20 16:31 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Simplify the widget rendering entry point (7.68 KB, patch)
2016-05-20 16:31 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add frame drawing API to GdkWindow (21.96 KB, patch)
2016-05-25 17:28 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Simplify the widget rendering entry point (8.06 KB, patch)
2016-05-25 17:28 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add frame drawing API to GdkWindow (22.19 KB, patch)
2016-05-26 11:44 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Simplify the widget rendering entry point (8.06 KB, patch)
2016-05-26 11:44 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add frame drawing API to GdkWindow (22.19 KB, patch)
2016-06-03 15:19 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Simplify the widget rendering entry point (8.06 KB, patch)
2016-06-03 15:20 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add GdkDrawingContext (13.34 KB, patch)
2016-06-03 15:20 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add frame drawing API to GdkWindow (22.19 KB, patch)
2016-06-06 13:57 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Simplify the widget rendering entry point (8.06 KB, patch)
2016-06-06 13:57 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add GdkDrawingContext (19.77 KB, patch)
2016-06-06 13:57 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
docs: Add GdkDrawingContext to the GDK API reference (1.98 KB, patch)
2016-06-06 13:57 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
Add frame drawing API to GdkWindow (21.37 KB, patch)
2016-06-07 16:10 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
Simplify the widget rendering entry point (8.16 KB, patch)
2016-06-07 16:10 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
Add GdkDrawingContext (21.19 KB, patch)
2016-06-07 16:10 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
docs: Add GdkDrawingContext to the GDK API reference (2.01 KB, patch)
2016-06-07 16:10 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
Associate the drawing context to the Cairo context (6.80 KB, patch)
2016-06-07 16:10 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
Deprecate the gdk_window_begin/end_paint family of functions (4.08 KB, patch)
2016-06-07 16:11 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
gdk: Explicitly create a cairo context inside GdkDrawingContext (2.84 KB, patch)
2016-06-07 16:11 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review
gdk: Deprecate gdk_cairo_create() (3.14 KB, patch)
2016-06-07 16:11 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Emmanuele Bassi (:ebassi) 2016-05-19 16:46:17 UTC
Discussed on IRC, and one of the line items that would simplify landing the GSK-based rendering code in GTK.

Edited copy-paste of the IRC discussion:

<~Company> ebassi: the big issue is that some places call begin_paint() themselves and then do funky stuff
<@ebassi> Company: As right now it's a bit all over the place, with various behaviours between gtk_widget_send_expose() and gtk_widget_draw()
<~Company> like gnumeric
<~Company> no idea what mozilla or libreoffice do
 * ebassi nods
<@ebassi> So, here's a bit of a prototype: http://paste.fedoraproject.org/368477/66549914
<@ebassi> It basically tries to move the "begin paint and get me a cairo context" down into GdkWindow
<@ebassi> (warning: it's a rough prototype)
<@ebassi> send_expose() would also call render() internally
<~Company> ebassi: double_buffered should not be an argument and it should behave as if it is true
<@ebassi> Company: Heh, I guessed that it would be an issue
<~Company> ebassi: also, I'm pretty sure I prefer begin_draw_frame() instead of begin_frame() for naming
<@ebassi> Right now, the 'double_buffered' is needed to avoid the special handling between begin_paint and draw directly
<@ebassi> Company: I'm not married to any naming, so it's fine by me
<~Company> what's the x_offset/y_offset about?
<@ebassi> Even 'double buffered' could be 'redirected'
<@ebassi> Company: It's the translation we do with _gtk_widget_get_translation_to_window()
<~Company> so, in my world, you cannot draw on any window but the root window
<~Company> and that's always at 0, 0
<~Company> all usages of child windows are bugs and need to be fixed
<~Company> and certainly shouldn't be available in new APIs
<@ebassi> Company: Okay
<~Company> ebassi: fwiw, if you begin_paint() on a client-side window today, I don't know what happens
<~Company> ebassi: client-sides certainly don't emit any expose events - those are all forwarded to the toplevel (because transparency)
<@ebassi> Company: So, if we want to enforce that particular bit in the API, we can also ensure that you call begin_draw_frame() only on top-levels/has-native windows
< mclasen> I would say we want an api that makes sense on a hypothetical future GdkToplevel
<~Company> ebassi: that's what I would do, yes
<@ebassi> This would get rid of some of the complexity downstream
<@ebassi> Cool
<~Company> it would work for what GTK needs from GDK
<~Company> might make the existing API harder to wrap - but I don't care about that, as long as it keeps working - even if it's slow
<~Company> like: What do we return from gdk_cairo_create() when begin_draw_frame() has been called and such things
<~Company> ebassi: also, it would be neat to forbid multiple calls to begin_draw_frame()
<~Company> so we don't end up with the double buffer stacking mess GDK does today
<@ebassi> Company: The nice bit of moving the association between window and cairo_t into GDK is that gdk_cairo_create() can return the same cr as begin_draw_frame()
<@ebassi> So you don't get weird results
<~Company> don't we do that already?
<@ebassi> Nope
<~Company> ah no, we just return the same surface
<~Company> but a different cairo_t
<@ebassi> Same surface, with the same clipping region
<@ebassi> But different cr
Comment 1 Emmanuele Bassi (:ebassi) 2016-05-20 16:31:10 UTC
Created attachment 328268 [details] [review]
Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
Comment 2 Emmanuele Bassi (:ebassi) 2016-05-20 16:31:15 UTC
Created attachment 328269 [details] [review]
Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.
Comment 3 Emmanuele Bassi (:ebassi) 2016-05-20 16:32:49 UTC
Proof of concept implementation of the API, for review.

I noticed that this introduces an interesting bug in GtkStack and GtkColorEditor, with the editor window being rendered on the target widget during the animation (use gtk3-widget-factory to see that). I'm currently tracking that down.
Comment 4 Emmanuele Bassi (:ebassi) 2016-05-24 15:42:23 UTC
It seems that the issue is caused by some odd interaction between the stacking order of windows inside a GtkOverlay and GtkStack transitioning a copy of the old widget.

Example: https://youtu.be/0KJlNyR40Rk
Comment 5 Emmanuele Bassi (:ebassi) 2016-05-25 17:28:16 UTC
Created attachment 328517 [details] [review]
Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
Comment 6 Emmanuele Bassi (:ebassi) 2016-05-25 17:28:24 UTC
Created attachment 328518 [details] [review]
Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.
Comment 7 Emmanuele Bassi (:ebassi) 2016-05-25 17:29:39 UTC
Trivial bug found: I wasn't bailing out early when rendering a widget, and ended up drawing too much.
Comment 8 Matthias Clasen 2016-05-25 23:53:29 UTC
Review of attachment 328517 [details] [review]:

::: gdk/gdkwindow.c
@@ +3124,3 @@
+ * @cr: a Cairo context created by gdk_window_begin_draw_frame()
+ *
+ * Retrieves the #GdkWindow that created the Cairo context @cr.

This sounds like it would return you the window back that was passed in to gdk_cairo_create(). But it doesn't...
Comment 9 Emmanuele Bassi (:ebassi) 2016-05-26 00:38:10 UTC
(In reply to Matthias Clasen from comment #8)
> Review of attachment 328517 [details] [review] [review]:
> 
> ::: gdk/gdkwindow.c
> @@ +3124,3 @@
> + * @cr: a Cairo context created by gdk_window_begin_draw_frame()
> + *
> + * Retrieves the #GdkWindow that created the Cairo context @cr.
> 
> This sounds like it would return you the window back that was passed in to
> gdk_cairo_create(). But it doesn't...

Indeed, it's likely an artifact of my debugging; I'll prepare a new patch that puts gdk_cairo_set_window() into gdk_cairo_create(), where I wanted to add it originally.
Comment 10 Emmanuele Bassi (:ebassi) 2016-05-26 11:44:19 UTC
Created attachment 328552 [details] [review]
Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
Comment 11 Emmanuele Bassi (:ebassi) 2016-05-26 11:44:26 UTC
Created attachment 328553 [details] [review]
Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.
Comment 12 Emmanuele Bassi (:ebassi) 2016-06-03 15:19:56 UTC
Created attachment 329054 [details] [review]
Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
Comment 13 Emmanuele Bassi (:ebassi) 2016-06-03 15:20:01 UTC
Created attachment 329055 [details] [review]
Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.
Comment 14 Emmanuele Bassi (:ebassi) 2016-06-03 15:20:07 UTC
Created attachment 329056 [details] [review]
Add GdkDrawingContext

Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
Comment 15 Emmanuele Bassi (:ebassi) 2016-06-03 15:24:26 UTC
These are the minimal patches that implement the API that Benjamin outlined on IRC; I'm also working on taking GdkDrawingContext and plugging it into the OpenGL pipeline by replacing gdk_cairo_draw_from_gl() — since that function only uses a Cairo context to extract all the current drawing state of the GdkWindow, which we can move into GdkDrawingContext.

Additionally, I've added hooks for backends to override the creation of the GdkDrawingContext so they can attach platform-specific data — e.g. a CGContext on OSX.

I kept the `DrawingContext` class name, but I'm not married to it; if somebody finds a better name I'm all up for renaming it.

I'm also working on a rebased GskRenderer branch that uses the GdkDrawingContext as the main entry point for rendering on a GdkWindow instead of using a GdkWindow, a Cairo surface, and a Cairo context.
Comment 16 Matthias Clasen 2016-06-05 13:35:48 UTC
This looks good to me; but lets see if Benjamin is happy with it now.
Comment 17 Emmanuele Bassi (:ebassi) 2016-06-06 13:57:40 UTC
Created attachment 329195 [details] [review]
Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
Comment 18 Emmanuele Bassi (:ebassi) 2016-06-06 13:57:46 UTC
Created attachment 329196 [details] [review]
Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.
Comment 19 Emmanuele Bassi (:ebassi) 2016-06-06 13:57:52 UTC
Created attachment 329197 [details] [review]
Add GdkDrawingContext

Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
Comment 20 Emmanuele Bassi (:ebassi) 2016-06-06 13:57:57 UTC
Created attachment 329198 [details] [review]
docs: Add GdkDrawingContext to the GDK API reference
Comment 21 Benjamin Otte (Company) 2016-06-06 15:20:17 UTC
Review of attachment 329195 [details] [review]:

Looks good. Some typos and a few random comments, but we can look at/argue those after landing.

::: docs/reference/gdk/gdk3-sections.txt
@@ +625,1 @@
 gdk_window_create_similar_image_surface

Why are gdk_window_create_similar_surface() and gdk_window_get_clip_region() gone from here?

::: gdk/gdkwindow.c
@@ +3167,3 @@
+
+  return window == tmp;
+}

I'm not sure we want this function. We only use it in gtk_cairo_should_draw_window() and it's trivial to copy/paste it into there.

And I'd rather not confuse casual readers of the API with such a weird function, when their mental model should ideally just be "every child window should be drawn".

@@ +3233,3 @@
+ *
+ * Indicates that the drawing of the contents of @window started with
+ * gdk_window_begin_frame() has been completed.

s/begin_frame/begin_draw_frame/
Comment 22 Emmanuele Bassi (:ebassi) 2016-06-06 15:29:30 UTC
(In reply to Benjamin Otte (Company) from comment #21)
> Review of attachment 329195 [details] [review] [review]:
> 
> Looks good. Some typos and a few random comments, but we can look at/argue
> those after landing.
> 
> ::: docs/reference/gdk/gdk3-sections.txt
> @@ +625,1 @@
>  gdk_window_create_similar_image_surface
> 
> Why are gdk_window_create_similar_surface() and gdk_window_get_clip_region()
> gone from here?

I have no idea. :-/

> ::: gdk/gdkwindow.c
> @@ +3167,3 @@
> +
> +  return window == tmp;
> +}
> 
> I'm not sure we want this function. We only use it in
> gtk_cairo_should_draw_window() and it's trivial to copy/paste it into there.

Okay.

> And I'd rather not confuse casual readers of the API with such a weird
> function, when their mental model should ideally just be "every child window
> should be drawn".

Yeah, fair point.

> @@ +3233,3 @@
> + *
> + * Indicates that the drawing of the contents of @window started with
> + * gdk_window_begin_frame() has been completed.
> 
> s/begin_frame/begin_draw_frame/

Fixed.
Comment 23 Benjamin Otte (Company) 2016-06-06 15:29:54 UTC
Review of attachment 329197 [details] [review]:

I like that you went through the pain of creating a whole object complete with properties.

::: gdk/gdkdrawingcontext.c
@@ +28,3 @@
+ *
+ * A #GdkDrawingContext can only be created by calling gdk_window_begin_draw_frame()
+ * and will be valid until a call to gdk_window_end_draw_frame().

Should there be a way to query the drawing context if it has been ended already, like cairo_surface_is_finished()?

I don't think we need it in C code because nobody sane will use refcounting on this object, but I have no idea about bindings.
And we could use that to return invalid cairo contexts for invalid drawing contexts instead of gdk_cairo_create()ing them.

::: gdk/gdkwindow.h
@@ +712,3 @@
 GDK_AVAILABLE_IN_3_22
 void          gdk_window_end_draw_frame    (GdkWindow            *window,
+                                            GdkDrawingContext    *cr);

I think I'd s/cr/ctx/ the variable name here.
Comment 24 Benjamin Otte (Company) 2016-06-06 15:32:02 UTC
Review of attachment 329198 [details] [review]:

Hrm, nowhere to put it in the other patches, so I'll just comment here:

We don't have a way to query the drawing context from the cairo_t, ie no gdk_cairo_get_drawing_context().
If we had that, we could also get rid of gdk_cairo_get_window() and replace it with gdk_drawing_context_get_window (gdk_cairo_get_drawing_context()).

Or is there a reason to not make the current drawing context queryable from a cairo_t?
Comment 25 Emmanuele Bassi (:ebassi) 2016-06-06 15:40:22 UTC
(In reply to Benjamin Otte (Company) from comment #23)
> Review of attachment 329197 [details] [review] [review]:
> 
> I like that you went through the pain of creating a whole object complete
> with properties.

Once I added the backend vfuncs, using properties felt more right than having to poke at the GdkDrawingContext instance structure fields directly.

> ::: gdk/gdkdrawingcontext.c
> @@ +28,3 @@
> + *
> + * A #GdkDrawingContext can only be created by calling
> gdk_window_begin_draw_frame()
> + * and will be valid until a call to gdk_window_end_draw_frame().
> 
> Should there be a way to query the drawing context if it has been ended
> already, like cairo_surface_is_finished()?

The :window should be NULL. I can add a gdk_drawing_context_is_valid() that checks that.

> I don't think we need it in C code because nobody sane will use refcounting
> on this object, but I have no idea about bindings.
> And we could use that to return invalid cairo contexts for invalid drawing
> contexts instead of gdk_cairo_create()ing them.

Good point.

> ::: gdk/gdkwindow.h
> @@ +712,3 @@
>  GDK_AVAILABLE_IN_3_22
>  void          gdk_window_end_draw_frame    (GdkWindow            *window,
> +                                            GdkDrawingContext    *cr);
> 
> I think I'd s/cr/ctx/ the variable name here.

Fixed.
Comment 26 Emmanuele Bassi (:ebassi) 2016-06-06 15:41:50 UTC
(In reply to Benjamin Otte (Company) from comment #24)
> Review of attachment 329198 [details] [review] [review]:
> 
> Hrm, nowhere to put it in the other patches, so I'll just comment here:
> 
> We don't have a way to query the drawing context from the cairo_t, ie no
> gdk_cairo_get_drawing_context().
> If we had that, we could also get rid of gdk_cairo_get_window() and replace
> it with gdk_drawing_context_get_window (gdk_cairo_get_drawing_context()).
> Or is there a reason to not make the current drawing context queryable from
> a cairo_t?

The problem with that is gdk_cairo_create() sets a GdkWindow, but there's no GdkDrawingContext at that point.

Unless we only allow people to call gdk_cairo_create() to a window with a GdkDrawingContext on it, in which case we can attach the drawing context to the Cairo context instead of the window.
Comment 27 Benjamin Otte (Company) 2016-06-06 15:44:44 UTC
(In reply to Emmanuele Bassi (:ebassi) from comment #26)
> The problem with that is gdk_cairo_create() sets a GdkWindow, but there's no
> GdkDrawingContext at that point.
> 
We could create one, ie do an implicit begin_draw_frame() if you call it.

Or we could just not have the window available for people that use this old outdated API. :)

That reminds me: Are we deprecating gdk_cairo_create(), gdk_window_begin_paint() etc APIs?
Comment 28 Emmanuele Bassi (:ebassi) 2016-06-07 15:17:52 UTC
(In reply to Benjamin Otte (Company) from comment #27)
> (In reply to Emmanuele Bassi (:ebassi) from comment #26)
> > The problem with that is gdk_cairo_create() sets a GdkWindow, but there's no
> > GdkDrawingContext at that point.
> > 
> We could create one, ie do an implicit begin_draw_frame() if you call it.

That would break callers using gdk_cairo_create() inside GTK, which does a gdk_window_begin_draw_frame() implicitly already — and we cannot have nested draw frames.

> Or we could just not have the window available for people that use this old
> outdated API. :)

This would be acceptable; people calling gdk_cairo_create() would not have an event window associated to it anyway.

> That reminds me: Are we deprecating gdk_cairo_create(),
> gdk_window_begin_paint() etc APIs?

I'd definitely deprecate the begin_paint_rectangle()/begin_paint_region()/end_paint(), as nothing outside of GTK should call them. We should be able to deprecate gdk_cairo_create() as well, and tell people to call gdk_window_create_similar_surface() and cairo_create(), if they want to get a separate cairo context to draw on based on a window. I'll add a documentation patch for that.
Comment 29 Emmanuele Bassi (:ebassi) 2016-06-07 16:10:35 UTC
Created attachment 329297 [details] [review]
Add frame drawing API to GdkWindow

Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.

This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.

This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
Comment 30 Emmanuele Bassi (:ebassi) 2016-06-07 16:10:41 UTC
Created attachment 329298 [details] [review]
Simplify the widget rendering entry point

Now that GDK has the appropriate API, we can simplify the widget drawing
code into a single function.
Comment 31 Emmanuele Bassi (:ebassi) 2016-06-07 16:10:48 UTC
Created attachment 329299 [details] [review]
Add GdkDrawingContext

Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
Comment 32 Emmanuele Bassi (:ebassi) 2016-06-07 16:10:53 UTC
Created attachment 329300 [details] [review]
docs: Add GdkDrawingContext to the GDK API reference
Comment 33 Emmanuele Bassi (:ebassi) 2016-06-07 16:10:59 UTC
Created attachment 329301 [details] [review]
Associate the drawing context to the Cairo context

Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.

Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.
Comment 34 Emmanuele Bassi (:ebassi) 2016-06-07 16:11:05 UTC
Created attachment 329302 [details] [review]
Deprecate the gdk_window_begin/end_paint family of functions

They are replaced by the more appropriate gdk_window_begin_draw_frame()
and gdk_window_end_draw_frame() functions.
Comment 35 Emmanuele Bassi (:ebassi) 2016-06-07 16:11:12 UTC
Created attachment 329303 [details] [review]
gdk: Explicitly create a cairo context inside GdkDrawingContext

Instead of using gdk_cairo_create(), which we'll soon deprecate.
Comment 36 Emmanuele Bassi (:ebassi) 2016-06-07 16:11:18 UTC
Created attachment 329304 [details] [review]
gdk: Deprecate gdk_cairo_create()

We have GdkDrawingContext, now, which is in charge of creating Cairo
contexts for drawing on a GdkWindow.
Comment 37 Matthias Clasen 2016-06-08 00:14:32 UTC
these patches all look fine to me
Comment 38 Emmanuele Bassi (:ebassi) 2016-06-09 19:04:38 UTC
Benjamin gave the accepted-commit_now for the previous patches, and these introduce the fixes he asked for.

Attachment 329297 [details] pushed as fc569f1 - Add frame drawing API to GdkWindow
Attachment 329298 [details] pushed as 2c7b217 - Simplify the widget rendering entry point
Attachment 329299 [details] pushed as a7ef37d - Add GdkDrawingContext
Attachment 329300 [details] pushed as 01b4bf1 - docs: Add GdkDrawingContext to the GDK API reference
Attachment 329301 [details] pushed as dda6a0d - Associate the drawing context to the Cairo context
Attachment 329302 [details] pushed as c5d0522 - Deprecate the gdk_window_begin/end_paint family of functions
Attachment 329303 [details] pushed as 2d38c40 - gdk: Explicitly create a cairo context inside GdkDrawingContext
Attachment 329304 [details] pushed as ad78daa - gdk: Deprecate gdk_cairo_create()