Since we now have a widget whenever we query tooltips, we can as well
get the events target_widget if we have an event (which is what we do
when coming from gtkmain.c). This keeps us from searching the entire
widget hierarchy for the target event even though we've already done
that for pointing events in gtkmain.c
This reduced the work done in gtk_tooltip_handle_event in normal motion
events to basically nothing since we already did all the heavy lifting
when handling the pointing event in gtkmain.c
As stated by the documentation, this should be called when a widget gets
updated, but in that case, one can equally use
gtk_widget_trigger_tooltip_query.
Setting it as qdata on the object doesn't save any memory since we use
the user_data as the event target, which every event has set these days.
This way is also faster since just reffing the object doesn't do any
locking.
If the text style changes, or the display settings do, we need to update
the state labels to ensure that the glyphs are available in the font
we're using.
The entire color scale hack is still done in GtkRange, which draws the
color scale in the range gizmo. So, to correctly redraw the color scale
when setting a new color, we need to redraw the proper widget and that's
the trough widget.
Fixes#1453
Instead of recording the way up from the target widget to the grab
widget (or toplevel) and then walking that path upwards, just walk the
parent chain and look at the cursor.
Most of the time, the GtkSnapshot objects we create while snapshotting
widgets don't end up containing all that many nodes or states in their
respective node or state stack. This undermines the amortized allocation
behavior of the G(Ptr)Array we use for the stacks. So instead, use the
(until now unused) parent_snapshot GtkSnapshot* passed to
gtk_widget_create_render_node and reuse its node and state stack.
We do not avoid allocating a new GtkSnapshot object, but we do avoid
allocating a ton of G(Ptr)Array objects and we also avoid realloc'ing
their storage.
Even though the IEC power glyphs are part of Unicode 9.0 (released in
2016) not all fonts have them.
To avoid showing the hexbox of doom when the system font does not have
the glyphs we'd like to use, add a fallback pair, using the old glyphs
we suggested when the labels were translatable.
The refactoring of automatically updating tree->root when setting a
node's parent works very well - unless all nodes get removed and no
node's parent got updated.
The tree is not needed to walk around the nodes.
It is however still needed for anything that requires modifying the
tree.
There is no immediate benefit in changing this API, but there might be
situations in the future where we can avoid looking up the tree when we
just want to check some details about the node.
Store a link to the tree in the root node. This allows looking up the
tree in O(log N) from the node without any extra memory usage.
This is useful because code can just store a pointer to the node and
doesn't need to keep the tree pointer around. And that can (for large
trees) save quite a bit of memory.
Searching through the tree is too specific to use a general function.
All the existing code just copies and slightly adapts the same 20 lines
instead, so there's no reason to keep the complicated API.
This broke the overlay blur demoe when resizing the window to a size
that would completely move the image below a button, causing the
GtkSnapshot code to remove the clip node below the blur node.
Considering the operations that some of the rendernode constructors
do, nodes with width or height 0 (or both of course) are very well
possible. This would break in the rendernodepaintable when adding a
transform, which divides by width/height of the rendernode.
We'd like the rose picture to be bigger than 16×16. Also remove the
scrolledwindow since the GtkPicture now automatically scales down the
rose image. This also fixes the picture always being allocated at y=0.
