We cannot unrealize a renderer in the dispose function, because that
would cause this chain to happen:
gsk_gl_renderer_dispose
gsk_renderer_dispose
gsk_renderer_unrealize
gsk_gl_renderer_unrealize
So we would call into thje GL renderers unrealize when it has already
(partially) disposed itself and ause accesses to dead variables.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Move away from the idea of intra-frame sampling, since we only
push samples once per frame, anyway. Instead, make the profiler
keep a rolling average of the last n frames.
If you set GTK_INSPECTOR_RENDERER to the same type of
values that GSK_RENDERER takes this can change the renderer
used for the inspector. This is useful if you're debugging
one renderer and don't want to affect the inspector.
Forces a full redraw every frame.
This is done generically, so it's supported on every renderer.
For widget-factory first page (with the spinner spinning and progressbar
pulsing), I get these numbers per frame:
action clipped full redraw
snapshot 0ms 7-10ms
cairo rendering 0ms 10-15ms
Vulkan rendering 3-5ms 18-20ms
Vulkan expected * 0ms 1-2ms
GL rendering unsupported 55-62ms
* expected means disabling rendering of unsupported render nodes,
instead of doing fallback drawing. So it overestimates the performance,
because borders and box-shadows are disabled.
... and implement it for the Cairo renderer.
It's an API that instructs a renderer to render to a texture.
So far this is mostly meant to be used for testing, but I could imagine
it being useful for rendering DND icons.
- Recognize "gl" as well as "opengl" for the GL renderer
- GSK_RENDERER=help now works
- g_warning() for an unrecognized renderer (typo detection!)
- g_print() the actual renderer that is used (and error messages when
selecting) when a GSK_RENDERER is given, so you'll notice if your
renderer isn't taken.
... 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.
This way, we don't spam criticals when GL is not available. Instead, we
print a useful debug message to stderr and continue with the Cairo renderer.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
and remove gsk_renderer_get_for_display().
This new function returns a realized renderer. Because of that, GSK can
catch failures to realize, destroy the renderer and try another one.
Or in short: I can finally use GTK on Weston with the nvidia binary
drivers again.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Instead of having a gsk_renderer_set_window() call, pass the window to
realize(). This way, the realization can fail with the wrong window.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
We do no longer bind textures to a renderer, instead they are a way for
applications to provide texture data.
For now, that's it. We've reverted to uploading it from scratch every
frame.
We need an overridable entry point for GskRenderer to create Cairo
surfaces.
Implementations of GskRenderer can override create_cairo_surface() to
create efficient surfaces, possibly with zero copies involved, depending
on the GDK backend.
While porting GTK to GskRenderer we noticed that the current fallback
code for widgets using Cairo to draw is not enough to cover all the
possible cases.
For instance, if a container widget still uses GtkWidget::draw to render
its children, and at least one of them has been ported to using render
nodes instead, the container won't know how to draw it.
For this reason we want to provide to layers above GSK the ability to
create a "fallback" renderer instance, created using a "parent"
GskRenderer instance, but using a Cairo context as the rendering target
instead of a GdkDrawingContext.
GTK will use this inside the gtk_widget_draw() implementation, if a
widget implements GtkWidgetClass.get_render_node().
We're going to need to allow rendering on a specific cairo_t in order to
implement fallback code paths inside GTK; this means that there will be
times when we have a transient GskRenderer instance that does not have a
GdkDrawingContext to draw on.
Instead of adding a new render() implementation for those cases and then
decide which one to use, we can remove the drawing context argument from
the virtual function itself, and allow using a NULL GdkDrawingContext
when calling gsk_renderer_render(). A later commit will add a generic
function to create a transient GskRenderer with a cairo_t attached to
it.
Renderers inside GSK will have to check whether we have access to a
GdkDrawingContext, in which case we're going to use it; or if we have
access to a cairo_t and a window.
The renderer will always use nearest-neighbor filters because it renders
at 1:1 pixel to texel ratio.
On the other hand, render nodes may be scaled, so we need to offer a way
to control the minification and magnification filters.
The details of the modelview and projection matrices are only useful for
the GL renderer; there's really no point in having those details
available in the generic API — especially as the Cairo fallback renderer
cannot really set up a complex modelview or a projection matrix.
Render nodes need access to rendering information like scaling factors.
If we keep render nodes separate from renderers until we submit a nodes
tree for rendering we're going to have to duplicate all that information
in a way that makes the API more complicated and fuzzier on its
semantics.
By having GskRenderer create GskRenderNode instances we can tie nodes
and renderers together; since higher layers will also have access to
the renderer instance, this does not add any burden to callers.
Additionally, if memory measurements indicate that we are spending too
much time in the allocation of new render nodes, we can now easily
implement a free-list or a renderer-specific allocator without breaking
the API.
