After trying to run Gooey again on my Mac for the first time in a few
weeks, I found that I ran into the Condvar issue again. Rather than
pasting AssertUnwindSafe in those files, I've both reported the
discrepency in unwind safety (rust-lang/rust#118009) and moved the
workaround into a type that only uses AssertUnwindsafe when compiling
for Apple.
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.
Asserting condition on PercentBetween, Color lerping now works
correctly according to testing with gray shades, but due to rounding
errors, no unit test is being checked in at the moment.
I noticed that the new default theme settings were causing the "wrong"
text color to be picked. After reviewing why the contrast values were
the way they were, I reasoned that the less lightness, the less the
ColorSource contrast matters. So I've applied a multiplication of the
average ligntess between the two colors being compared.
Introducing two new colors:
- ColorTheme::color_dim, for dimmed/disabled primary colors
- SurfaceTheme::opaque_widget, for buttons.
In material design, a button's background color uses the Highest
Container role, which seems incorrect because then buttons wouldn't have
a different color when placed inside of the highest level container.
Rather than remove a container level, I added one more tone using the
neutral variant.
Other changes are just gut feelings to have a slightly richer dark
theme. I feel like material is a little muddy in dark mode.
I started making more changes, and I lost track of what was merge
related and what wasn't, so I committed the merge with what was staged,
but it probably didn't compile.
This is the remaining changes to get things back to a state I'm happy
with, mostly tweaking the constrast behavior.
