map_each previously was written such that if a chain of mappings fed
each other, a deadlock could occur because while the first one was
mapped, the second callback gets invoked and tries to update the first
value while it's still being held.
This refactor switches from std Mutex to parking_lot, allowing me to
remove a workaround for needing to run drop callbacks in a separate
thread during the drop of a DynamicGuard.
In addition to that change, the lower level `map_generational` calls now
take a DynamicGuard as their parameter. This allows these functions to
drop ownership of the referenced data during the callback.
The map_each implementation takes advantage of this by ensuring that the
guard is dropped before set is invoked, minimizing potential lock overlaps.
With this refactor, some old code of mine with complex validations now works
again.
Closes#138
This implementation works around most of the locking issues that arose
the first few times I tried fixing this. Unfortunately it's been just
long enough for me to forget how I triggered some catastrophic issues in
the past, but all of the current examples that would invoke this
behavior continue to work, and some of the side projects that have some
weird usages also still work.
This cascaded into a lot more work than expected. However, in general,
if one clones a `WidgetInstance` and shares it between two windows, it
should now work. Widget authors must ensure that when they cache
information, they do so with either a `WidgetCacheKey` or use a
`WindowLocal<T>` if per-window state is desired.
This is demonstrated in the debug-window example, where the counter of
open windows is next to a clone of the same button from the main window
that opens a new window.
While this was a workaround for a docs.rs issue (Px/Lp are not
linked), I decided having the shorter import path would look better in
the examples.
It probably wasn't necessary to update all of the references in the
internal code, but I decided it was worth the consistency.
The issue was that my last set of changes were causing the animations to
restart, causing the animation to keep being extended to another 150ms.
I think the only way for this to work is to switch to an event
mechanism to notify widgets once they've been invalidated. This event
could include a parameter stating whether it was a direct invalidation
or an invalidation due to another widget in the hierarchy. Button
doesn't really care about the rest of the hierarchy, it only cares about
its own state, and the cache key was including too many changes.
This also fixes some inconsistencies that arose when the focus widget
was "stuck" on a removed widget. Button previously handled it hackily in
a redraw function, but now Gooey handles it automatically without
needing to wait for a repaint.
Given the goal of this function, I'm not sure it can get more optimal
than this even with specialized data structures like KD-trees. The
problem is that we want all widgets that are hovered, not just some, and
that makes nearest neighbor useless.
The main optimizations here are simple:
- Group up all the render data we need in a single vec to help cache.
- Precompute the rect's extents to make the contains check at most 4
comparisons.
This had a noticable effect on the "wiggle the mouse frantically"
performance, where Gooey isn't actually repainting but is routing mouse
events.
measure() now is layout(). LayoutContext can either persist layout
information or be used temporarily for measurement. While this caching
is constantly thrown out currently, this is a step towards being able to
only re-layout widgets if they've been invalidated.
