1b9aa1b708 ('a11y: drop the focus tracker') removed a bit too much. We
still have to emit window:activate/deactivate events. They are easy to
emit anyway.
Fixes#127
Overlays are drawings that get rendered on top of the inspected window.
The only overlay in existence so far is the highlight overlay, which is
used to highlight widgets and replaces the "draw" signal handler used
previously.
Instead of just notifying the inspector of what is going to be rendered,
allow the inspector to modify it.
This way, the inspector can overlay information it deems relevant over
the render node while still having access to what the actual widget
(without the inspector) would paint.
If you want to draw a widget to cairo today, you create a widget
paintable, snapshot it to a render node and then draw the render node to
cairo.
And yes, this is that complicated on purpose. Don't draw widgets to
Cairo.
This allows being more specific about the size.
It's useful in particular when the resulting render nodes might be
too small for the size, not only when they are too large. For the
latter case, using a clip node would be enough.
It also requires adding a clip node when rendering the resulting
paintable, but that should be optimized out by GtkSnapshot when not
necessary.
This is actually not just a mechnaism to protect against too many
signals, but it's also a method to getting those signals at the wrong
time.
For every size/content change, a widget needs to invalidate twice:
Once when it queues a resize/redraw (going valid => invalid) and once
when the new size/content is actually assigned (going invalid => valid).
However, one of those invalidations might be inconvenient for the
listener. GtkImage for example does not like receiving
invalidate-contents signals when new contents are assigned, but is fine
with them when the old ones go invalid. And it will not try to draw the
paintable in between anyway.
So by bypassing the 2nd emission if nothing was changed, we can make
GtkImage happy.
This error message is printed into the journal if a GTK app can't
connect to eithre Wayland or X11. Make it at least mention who is not
capable of connecting to a server.
Unrelated, we might want to improve our error reporting when a GTK app
can't start, so that debugging issues with system startup / login get
easier to resolve.
When the clip changes that is passed to a snapshot function, we need to
create eventual cached render nodes because they might not have drawn
their whole area before.
Fixes issues with redrawing when scrolling.
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.
Instead of calling gdk_surface_invalidate_region(), just
gdk_surface_queue_expose() and rely on the renderer computing the diff
from the previous rendering.
... 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.
Now that we don't clip the created render nodes anymore, we don't have
to compute the clip region beforehand.
So snapshot the render nodes before initializing the renderer.
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).
This requires a bunch of refactorings:
1. Don't pass the current clip region to gtk_widget_snapshot()
so we don't create full widget contents
3. Have a widget->priv->draw_needed that we invalidate on every
queue_draw() call and set on every snapshot()
2. In queue_draw(), walk the widget chain to invalidate the
render nodes of all parents
... 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.
