-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store UI render target info locally per node #17579
Store UI render target info locally per node #17579
Conversation
Change `update_target_camera_system` to update the `ResolvedCameraCamera` components.
Renamed `NodeScaleFactor` -> `ResolvedScaleFactor`
Co-authored-by: UkoeHB <[email protected]>
… into resolved-ui-context
Thanks for reviewing this. I agree, ran some benchmarks and I was definitely overestimating the benefits of more granular change detection. In practice changing the resolution or scale factor is almost always going to result in a full relayout of everything so there's no benefit to having the separate components. |
… into resolved-ui-context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is much more sensible. I've left a suggestion for improved docs for the new component.
Objective
It's difficult to understand or make changes to the UI systems because of how each system needs to individually track changes to scale factor, windows and camera targets in local hashmaps, particularly for new contributors. Any major change inevitably introduces new scale factor bugs.
Instead of per-system resolution we can resolve the camera target info for all UI nodes in a system at the start of
PostUpdate
and then store it per-node in components that can be queried with change detection.Fixes #17613
Fixes #17578
Fixes #15143
Solution
Store the UI render target's data locally per node in a component that is updated in
PostUpdate
before any other UI systems run.This component can be then be queried with change detection so that UI systems no longer need to have knowledge of cameras and windows and don't require fragile custom change detection solutions using local hashmaps.
Showcase
Compare
measure_text_system
from main (which has a bug the causes it to use the wrong scale factor when a node's camera target changes):with
measure_text_system
from this PR (which always uses the correct scale factor):Testing
I removed an alarming number of tests from the
layout
module but they were mostly to do with the deleted camera synchronisation logic. The remaining tests should all pass now.The most relevant examples are
multiple_windows
andsplit_screen
, the behaviour of both should be unchanged from main.