Commit Graph

13 Commits

Author SHA1 Message Date
Timm Bäder
b6ee3490c3 GdkDrawingContext: Add missing nullable annotation 2018-01-10 08:46:22 +01:00
Matthias Clasen
ca2a7c1efd Document more structs 2017-12-26 14:39:24 -05:00
Timm Bäder
56e809be9c GdkDrawingContext: Add missing break in switch statement 2017-03-18 07:07:06 +01:00
Benjamin Otte
ca78f5d3cb gdk: Make gdk_window_begin_draw_frame() take a draw context
... instead of a gl context.

This requires some refactoring in the way we mark the shared context as
drawing: We now call begin_frame/end_frame() on it and ignore the call
on the main context.
Unfortunately we need to do this check in all vfuncs, which sucks. But I
haven't found a better way.
2016-12-05 15:02:47 +01:00
Benjamin Otte
e38bd27d58 gdk: Redo GL drawing
Reenable GL drawing, but do it without Cairo.

Now, the context passed to gdk_window_begin_draw_frame() decides how
drawing is going to happen. If it is NULL, Cairo is used like before.

If a context is passed, Cairo may not be used for drawing and
gdk_drawing_context_get_cairo_context() is going to return NULL.
Instead, the GL renderer must draw to the GL backbuffer and
end_draw_frame() is then swapping that to the front.

The GskGLRenderer has lost the texture it used to render to and adapted
to render directly to the backbuffer instead.

The only thing missing is for GtkGLArea to gain back a performant way to
render. But it didn't have one since the introduction of GSK, this
patchset doesn't change anything about it.

The new rendering avoids two indirections (the GSK renderer's texture
and the GDK double buffering surface).
It improves icon count in the fishbowl demo by 30%.
2016-12-05 15:02:47 +01:00
Benjamin Otte
332ed7be5b API: Require passing a GLContext to begin_draw_frame()
This is in preparation for requiring explicit passing of GL contexts
when drawing.
2016-12-05 15:02:47 +01:00
Benjamin Otte
a860bbbe46 drawingcontext: Store the GL paint context 2016-12-05 15:02:47 +01:00
Benjamin Otte
4dedafb79b drawingcontext: Add a private struct
This is to control what backends can and cannot access.
2016-11-23 18:49:48 +01:00
Emmanuele Bassi
0ca59bf85a gdk: Unset the DrawingContext <-> cairo_t link on dispose
When disposing a GdkDrawingContext we should unset the association
between the instance and the Cairo context; this avoids stale pointers
in case a reference that has acquired on the Cairo context survives the
lifetime of the GdkDrawingContext.
2016-06-12 18:55:34 +01:00
Emmanuele Bassi
222bcf1a71 gdk: Try harder at tracking drawing contexts
If gdk_cairo_create() is called within a frame draw operation, we can
still associate the Cairo context with a GdkDrawingContext.
2016-06-12 17:27:44 +01:00
Emmanuele Bassi
2d38c40f78 gdk: Explicitly create a cairo context inside GdkDrawingContext
Instead of using gdk_cairo_create(), which we'll soon deprecate.

https://bugzilla.gnome.org/show_bug.cgi?id=766675
2016-06-09 17:45:40 +01:00
Emmanuele Bassi
dda6a0d385 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.

https://bugzilla.gnome.org/show_bug.cgi?id=766675
2016-06-09 17:45:40 +01:00
Emmanuele Bassi
a7ef37da2a 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.

https://bugzilla.gnome.org/show_bug.cgi?id=766675
2016-06-09 17:45:40 +01:00