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.