So we can check that the currently set clip is the first one and now
intersect with it. This first clip is always the entire viewport or the
entire render_area and we don't want to end up drawing things to a
texture because of it.
Instead of getting the translation x/y everytime we use the modelview,
get it once, when extracting the metadata. Do the same with the scale.
And save if the matrix is "simple" at all, i.e. if it only consists of a
translation and/or scale. This will be helpful later when we start
drawing transformed nodes on textures.
We do this for every single node, which is a little costly, especially
since the common case for the modelview matrix these days is a simple
translation. So, check whether the new modelview matrix is only a
translation matrix and if so, don't do a full matrix multiplication per
node.
Some of the _diff implementations did a whole bunch of work just to
throw it away afterwards and invalidate the entire union of the two
render nodes, most notably the two clip nodes. Fix this to only call
gsk_render_node_diff_impossible if the previous if-condition is FALSE
and not always.
This reverts commit 8e74eb382f.
This code is not necessary. It worked around a bug in graphene where
graphene was requiring stricter alignment than glib allocators could
guarantee.
Any data that is later fed to graphene must be
allocated with proper alignment, if graphene
uses SSE2 or GCC vector instructions.
This adds custom array code (a streamlined copy
of GArray with all unnecessary bells and whistles removed),
which is then used for the state_stack instead of GArray.
There's also a runtime check for the size of GtkSnapshotState
itself being a multiple of 16. If that is not so, any array
elements past the 0th element will lose alignment.
There are probably struct attributes that can
make GtkSnapshotState always have size that is a multiple
of 16, but we'll burn that bridge if we cross it.
The code is mostly stolen from graphene.
Allocators support any alignment, but their implementation
only calls system aligned allocator functions if malloc()
is not aligned to 16-byte boundaries. If it is aligned,
the implementation just calls malloc() regardless of which
alignment is requested by the caller.
This can be fixed by saving the result of meson malloc()
alignment check and adding a few conditions to the implementation,
but right now GSK and GTK only need 16-byte alignment either way.
1. Include the broadway renderer (so we can test it properly fails on
Wayland or X11)
2. List all potential renderers, print useful information when Vulkan
is not compiled in instea dof omitting it
3. Improve docs
As they require a draw context and the draw context is already bound to
the surface, it makes much more sense and reduces abiguity by moving
these APIs to the draw context.
As a side effect, we simplify GdkSurface APIs to a point where
GdkSurface now does not concern itself with drawing anymore at all,
apart from being the object that creates draw contexts.
Previously, we got the damage, then computed the changed area, then
started a frame with that changed area.
But starting a frame computes the damage for us.
So now we start a frame, then get the damage area from that, then
compute the change area.
This does nothing but disallow passing NULL to gdk_surface_begin_paint()
and instead require this context.
The ultimate goal is to split out Cairo drawing into its own source file
so it doesn't clutter up the generic rendering path.
And of course, gsk_render_node_get_name() is gone, too.
The replacement is of course debug nodes.
As a side effect, GskRenderNode is now *really* immutable.
We pulled out the bounds calculation for performance reasons, but the
caller can't know how to properly compute them. Inside gtk+, we can do
that but it's not good enough for public API.
When the max cost for finding a path gets to high, the diff can now be
aborted.
Because render nodes have a fallback method (by just marking the whole
bounds of the nodes as different), we use this to improve performance
of diffs.
This brings fishbowl (which is basically a container node with N images
that change every frame) back to close to previous performance.
Now that we have the full render nodes available, there is not much
benefit in fine-grained control over multiple rectangles.
In particular, it's causing pain with complex regions.
There might be a benefit in clipping to the region's rectangles in cases
like widget-factory where the whole diff is made up of the 2 rectangles
of spinner and the pulsing progress bar, but it needs a good heuristic
for where this is useful.
... and diff the previous node with the current one to determine the
clip region.
This doubles the work necessary to track clip regions, but the following
commits will clean that up.
It doesn't need to be exported anymore.
As a side effect, the inspector no longer has any information about the
render region, so remove the code that was taking care of that.
This includes a copy of the diff(1) algorithm used by git diff by Davide
Libenzi.
It's used for the common case ofcontainer nodes having only very few
changes for the few nodes of child widgets that changed (like a button
lighting up when hilighted or a spinning spinner).
... and gsk_render_node_can_diff(). Those are vfuncs to compute a region
containing all the pixels that differ between the two nodes.
This is just the plumbing that chains into node classes. No node
implements it yet.
