Function: registerUiSystems()
registerUiSystems(
world,renderContext,time,options?):void
Defined in: ui/utilities/register-ui-systems.ts:92
Registers every system a createUiCanvas canvas depends on: layout,
layout groups, aspect ratio fitting, progress bars, canvas groups, focus
navigation, color transitions, toggles, and tooltips - plus, once a
pointerSource is supplied, pointer raycasting/interaction/sliders, and
once getSafeAreaInsets is supplied, safe-area insetting - each wired in
the order their cross-system reads/writes require.
Call this once per EcsWorld, the same way a game calls registerInputs
once regardless of how many input sources/actions it adds afterwards -
world.addSystem has no built-in protection against registering the same
kind of system twice, so calling this more than once for the same world
would double-process every canvas each tick (e.g. firing onInvoke twice
per submit). Create as many canvases as you like afterwards with
createUiCanvas, which only creates the canvas entity itself and doesn't
touch system registration.
Registration order: raycast, then navigation, then interaction, then
toggle/transition/tooltip (order between those three doesn't matter, none
reads another's writes), then slider - raycast must run before navigation
and interaction read its hit-test result, interaction must run before
transition/tooltip read the interaction state it just wrote, navigation
must run before interaction because navigation is what resets
wasInvokedThisFrame to false each tick before interaction
conditionally sets it back to true for the pointer path, toggle/tooltip
must run after both navigation and interaction for the same reason, and
slider must run after interaction (it reads pressCapture). Progress
bars/aspect ratio fitting/layout groups have no interaction dependency
and run before layout, so a value they write is resolved into a rect the
very same tick rather than lagging a frame behind; canvas groups run
after layout so every UI system's relative order stays predictable.
The caller is still responsible for registering createTransformEcsSystem
and createRenderEcsSystem with world - after this call, so the
layout system (which writes position.local) runs before the transform
system (which reads it to compute position.world), which in turn must
run before the render system. Both are ordinary, already-existing systems
a game registers once regardless of UI, so this doesn't register a second
instance of either.
Parameters
world
The ECS world to register the UI systems with.
renderContext
The render context the layout/raycast/interaction/ slider/safe-area systems resolve canvas roots and pointer positions against.
time
The time instance driving createUiTransitionEcsSystem's
and createUiTooltipEcsSystem's timers.
options?
The pointer source and safe-area callback to wire up, if this game uses them.
Returns
void