This allows renderers (or anyone really) to attach "render data" to
textures. Only the first render data sticks.
You can gsk_texture_set_render_data() with the key you will use to
look the data up again, and if no data has been set yet, yours will be
set.
You can retrieve this data via gsk_texture_get_render_data() later on.
If your data has been cleared, NULL will be returned.
When gsk_texture_clear_render_data() is called (which the texture will
call when it is finalized), your destory notify will be called and you
have to release your render data.
The GL driver uses this to attach texture ids to GskTextures.
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.
This happens in regular code paths for example when trying to render the
empty text string. We don't want to store a surface on the render
node in such a case (so actual rendering isn't slowed down), but we do
want to return a working cairo context that is not in an error state
(so the cairo rendering can continue without error messages).
Now that GTK+ is built as a single DLL, and the .lib that is built is
gtk-4.lib, we need to update the autotools sections in generating the
NMake Makefile snippets so that we can have the correct commands and flags
for building the .gir files, which will all now link to gtk-4-vsXX.dll (or
so).
Now that the autotools build folded the GDK/GSK bits into the main GTK+
DLL, there are some updates that need to be done for this. We need to:
-Fold the DllMain() of GDK-Win32 into the main GTK+ DllMain(), as we need
the HINSTANCE to register the window. We can't have two DllMain()'s in a
single DLL.
-Remove the GDK rc(.in) files, as that is not used anymore. Make the GTK+
.rc(.in) file load the gtk.ico GTK+ logo file instead so that we still
get the GTK+ logo for the application icon by default. Update the
autotools build files as well.
-Revert commit b9f9980 as LRN pointed out in comment 25 in bug 773299, as
GTK+ is now a monolithic DLL, and we ought not to export this private
function.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
gtk/inspector/rendernodeview.c calls this private function from GSK, so we
need to ensure that this function is exported so that GTK+ can link
properly on compilers that do not support automatic exporting.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The GLSL versions are:
OpenGL 2.1: #version 110
OpenGL 3.0: #version 130
OpenGL 3.2: #version 150
OpenGLES 2.0: #version 100
OpenGLES 3.0: #version 300 es
So we need to check the version of the GdkGLContext if we want use the
appropriate version, especially for legacy OpenGL contexts, which can be
both 3.x and 2.x.
We want to have the coordinate system of the created cairo surface to be
identical to the coordinate system of the node's bounds. For that, we
need to translate the cairo surface by the bounds' origin.
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.
This merged gtk, gdk and gsk into one library, making it possible to
have internal private APIs between gtk them, as well as producing more
efficient code.
https://bugzilla.gnome.org/show_bug.cgi?id=773100
This adds the initial MSVC build items needed to build GSK under Visual Studio,
this is part of it that is required, we need to add items to the property sheets
to generate the code that is generated via glib-mkenums and glib-compile-resources.
This set includes, with the autotools scripts for the complete:
-GSK project files, which is integrated into the gtk+-4.sln.
-The NMake snippets to build the introspection files for GSK.
-The .bat files to call glib-mkenums to generate the enumeration sources.
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.
GskRenderNode is, at its core, a write-only API; you're supposed to set
up the render nodes instead of querying them for state.
Querying render nodes is left to the GskRenderer implementation.
We store the vertices in (unscaled) window coords (but the item size
is still scaled to match the texture size). Also, the
projection/model-view multiplication order is switched so that the scale
is applied at the right place.
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.
If we already have a GL texture we definitely don't want to use
gdk_cairo_draw_from_gl() to draw on a Cairo context if we're going
to take the Cairo surface to which we draw and put it into an OpenGL
texture.
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.
Just like we reuse texture ids with the same size we can, at the expense
of a little memory, reuse vertex buffers if they reference the same
attributes and contain the same data.
Each VAO is marked as free at the end of the frame, and if it's not
reused in the following frame, it gets dropped.
The child-transform is useful only if we also provide clipping to the
parent nodes, otherwise children will just be drawn outside of the
parent's bounds.
We'll introduce child transforms either at a higher layer, or once we
add clipping support to GskRenderNode.
I don't think this should stay in the code long-term, but it
is useful for debugging. It helped me track down some suspicious
placements of render nodes.
Instead of passing the size of the buffer, we should pass the number of
quads; we know what the size of a single quad structure is, so we can do
the multiplication internally when creating the VAO.
This allows us to print the quads for debugging purposes.
