Fix debug-profile slider stutter (#25500)

[bugsweeper]

Objective

• Fixes feathers_gallery poor performance in debug mode #25500.
• On debug builds, dragging the color slider/color plane in feathers_gallery updated in visible discrete steps instead of smoothly. Measured on Linux + NVIDIA RTX 4070 + Vulkan: out of 138 consecutive frames during a slow, controlled drag, only 86 states were unique (52 frames repeated the previous state) in debug, versus 129/138 unique in release. The slider's value updated correctly the whole time — this was a rendering smoothness problem, not an input problem.
• Two causes were found:
  • EditableText triggered a full intrinsic-size recomputation (and thus a full Taffy layout pass) every frame, regardless of whether its rendered size had actually changed.
  • ColorSlider and ColorPlane moved their thumb every frame by writing Node::left/Node::top, which are layout-affecting properties and force a Taffy relayout on every frame during a drag.
  • Both are comparatively cheap in optimized builds but expensive enough in debug builds to visibly drop frames.

Solution

• update_editable_text_content_size now caches the inputs that actually determine EditableText's intrinsic size (visible_width, visible_lines) in a new EditableTextContentSizeState component, and only recomputes when those specific fields change, instead of on every change to EditableText (which also churns from unrelated fields like cursor blink/edits). EditableTextContentSizeState is wired up as a required component of bevy_text::EditableText via register_required_components in UiPlugin, since bevy_text doesn't depend on bevy_ui.
• ColorSlider and ColorPlane now position their thumb via UiTransform instead of Node::left/Node::top. UiTransform is applied after layout and doesn't invalidate Taffy, so moving the thumb no longer forces a relayout.
• ColorPlane's thumb positioning was split out of update_plane_color into its own system, update_plane_thumb_position, which runs unconditionally every frame so the thumb keeps tracking the parent node's actual size (e.g. on window resize) even when the color value hasn't changed. update_plane_color keeps its original Changed filter, since it mutates Assets<ColorPlaneMaterial>, which is comparatively expensive to touch every frame.

Testing

• cargo test -p bevy_ui --lib: 66/66 passed.
• cargo test -p bevy_feathers --lib: 10/10 passed.
• cargo fmt --check and git diff --check pass.
• Manually verified in feathers_gallery (debug profile) that the color slider and color plane thumbs track the mouse correctly and land at the right position during and after a drag.
• Manually verified that resizing the window while the color plane is visible keeps its thumb tracking the container's size correctly, both with and without a value change in between.
• Measured debug-profile FPS during continuous slider drag: ~11-14 FPS before this fix, ~59-63 FPS after, both at rest and while continuously dragging.
• Tested on Linux + NVIDIA RTX 4070 + Vulkan only. Not tested on Windows/macOS or other GPU vendors; the fix is platform-agnostic (it removes unnecessary layout/material work), so I don't expect platform-specific regressions, but review/testing on other platforms is welcome.

[bugsweeper]

The macOS build job did not report a test failure; it was cancelled after reaching the workflow’s 40-minute timeout while running cargo run -p ci -- test. Ubuntu and Windows builds passed, as did run-examples-macos-metal. I’ll update the branch against current main to trigger a fresh run. If macOS times out again, could a maintainer please rerun the failed job?

[cookie1170]

tested it for myself, debug-mode performance did improve a lot! sadly the normal slider is still laggy, though i imagine similar changes there might not work since it actually needs to change size
i'm not entirely sure how often this would matter in real setups, however, since even the quick start guide recommends you compile bevy with opt 3

[bugsweeper]

@cookie1170 Thanks for testing and pointing out the normal slider - it was using a different code path and was indeed still triggering a full UI layout while dragging.
The value label was remeasured on every update, and replacing its ContentSize invalidated Taffy even when the measured size had not changed. I’ve now made the label explicitly non-wrapping and cached its last intrinsic size, so glyphs are still updated every frame, but layout is only invalidated when the label’s dimensions actually change.
In the feathers_gallery debug build, this reduced the average ui_layout_system time from about 61 ms to 11 ms and increased the number of processed frames in the same profiling interval from 90 to 285. There may still be an occasional slower frame when the label genuinely changes width, such as 9.00 -> 10.00, but regular dragging should now be substantially smoother.
So this was worth fixing independently of the recommendation to use opt-level = 3: debug mode exposed a real case of unnecessarily invalidating the full UI layout.

[alice-i-cecile]

I'd like to merge this for 0.20: are you able to resolve merge conflicts? :)

[bugsweeper]

@alice-i-cecile

Sure - I've resolved the merge confilcts against the lastest main and all the tests passed.