This also removes the return if fail macros from these as a good portion
of them didn't have them anyway. I think it's fair to say that access to
these incorrectly is a programmer error.
It significantly reduces the amount of code generated into generally a
movss,ret.
The use of volatile was incorrect in GLib and has been that way for
a long time. Recently however that has changed, and this makes GTK
follow suit to avoid using volatile in the type registration.
See also: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719
Combined with the above merge request for GLib, this fixes a large
number of compilation warnings when using Clang.
A GskGLShader is an abstraction of a GLSL fragment shader that
can produce pixel values given inputs:
* N (currently max 4) textures
* Current arguments for the shader uniform
Uniform types are: float,(u)int,bool,vec234)
There is also a builder for the uniform arguments which are
passed around as immutable GBytes in the built form.
A GskGLShaderNode is a render node that renders a GskGLShader inside a
specified rectangular bounds. It renders its child nodes as textures
and passes those as texture arguments to the shader. You also pass it
a uniform arguments object.
Now that the GskRenderNode subclasses are recognised as proper
sub-types, we can annotate the constructors with their type. The C API
remains the same.
The introspection scanner tries to match a type name with a get_type()
function, in order to correctly identify a type as a class.
If the function is not available, we have two choices:
- add some special case inside the introspection scanner, similar to
how GParamSpec subclasses are handled in GObject
- add a simple get_type() function
The latter is the simplest approach, and we don't need to change that
much, since we still register all render nodes at once.
Language bindings—especially ones based on introspection—cannot deal
with custom type hiearchies. Luckily for us, GType has a derivable type
with low overhead: GTypeInstance.
By turning GskRenderNode into a GTypeInstance, and creating derived
types for each class of node, we can provide an introspectable API to
our non-C API consumers, with no functional change to the C API itself.
