ui_scaling example is jittery

[rparrett]

Bevy version

Since #9784

Relevant system information

AdapterInfo { name: "Apple M1 Max", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
SystemInfo { os: "MacOS 13.6.2 ", kernel: "22.6.0", cpu: "Apple M1 Max", core_count: "10", memory: "64.0 GiB" }

Tested with scale_factor of 1.0 and 2.0.

What you did

cargo run --example ui_scaling
Press up arrow.

What went wrong

Animation isn't smooth. Things are jittering all over the place.

ui_scaling.mp4

Additional information

I'm not sure if this is a bug, or if the example needs to be reworked, or new expected behavior. This is just something I noticed in passing and wanted to document.

[pablo-lua]

I did some digging on that field
Explaining very shortly, there is a notable change in the Frame main position, probably caused by the GlobalTransform and Node::size() being mistaken somehow
So, I did some debugging in that example, marking the change in the Transform translation and node size (they are all calculated by window_scale * ui_scale, that being an important factor on the calculation)

• Every frame here is 2 lines, and they only activate when the UiScale is changing !
  

The expected translation and size is here as follow (when the UiScale doesn't change)

Somehow, the UiScale is out of sync, and I'm not sure why
Other test that I did is Skipping one frame, and the problem is probably not some weird race condition
there is the possibility that the children are causing that jittering
Finally, I found out that the jittering exist even without children, removed the children of the node and the rect keeps moving

[rparrett]

Just so this doesn't get lost:

Pablo Lua
Is there a reason why we round the ui numbers?

nicoburns
The rounding is to ensure that thin lines (and text) in the UI can be drawn pixel-aligned and therefore sharp rather than fuzzy. The fixes to the rounding were to deal with a bug that was causing there to be gaps in the UI due to rounding issues. The rounding implementation atm is not ideal because while rounding occurs in physical coordinates, those values are subsequently converted to logical coordinates and back again after the rounding. For bug-free rounding, it ought to occur with physical coordinates at a stage beyond which logical coordinates are no longer used.

[rparrett]

Seems fixed by #16097