Caret animation
John Hendrikx
john.hendrikx at gmail.com
Wed Dec 27 05:53:56 UTC 2023
In light of a possible future Behavior API, I took a close look at the
"complicated" behaviors surrounding TextFields and TextAreas.
One thing that came out of this is that caret animation is controlled by
the behaviors by looking at key presses and keys typed. It is a very
convoluted way of doing this as there is a much simpler rule that
governs caret animation:
*when the caret moves, animation should be reset*
This is how controls do it in browsers and on Windows, and it makes much
more sense. The caret only needs highlighting when it actually changed
position, and can remain animated when it doesn't.
This also means that caret blinking can simply be a concern of the Skin,
as it can listen for caret position changes. This also makes more
sense. Replacing the Behavior but keeping the same Skin should not
break caret blinking.
Currently, the behaviors will wrap all possible key pressed/typed events
to stop the blinking, but it gets it wrong in many situations (when the
caret didn't actually move, or when a key press was not consumed or
didn't do anything, or using keypad navigation which "forgets" to wrap
it in the start/stop animation logic). It feels like a big hack when
there is such an obvious alternative.
I've created this ticket to address this:
https://bugs.openjdk.org/browse/JDK-8322748
One of the immediate benefits (aside from solving all caret animation
bugs) is probably a memory reduction as it removes a wrapper around
every key press/type mapping...
--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231227/a900df01/attachment.htm>
More information about the openjfx-dev
mailing list