ScrollView scrolling delta and ConstantPhysicalSize ScaleMode

[nz2develop]

When using ConstantPhysicalSize ScaleMode for RuntimeUI in PanelSettings Unity treats specified dimension values in pixels as Constant Physical Size units, so the elements of UI appear properly on screens with different densities.

And then the scrolling deceleration of ScrollView seems to operate in its calculations in those “virtual” pixels, so before the scaling occurs, and therefore when the DPI is high enough, the deceleration animation might be not smooth, especially right before the stop.

One solution is to make the UI in actual pixel size, and then scale with constant Pixel size or scale with screen size, and use high-resolution screen reference, so the scaling occurs downwards. (In this case, doing the adaptive UI becomes more challenging, as now you have to specify all dimensions in pixels)

The other solution would be for the PanelSettings, and the UI Scaller to somehow let ScrollView know in which ratio it is scaling at the moment, so the scrolling calculation is in respect to the actual pixels.

Currently, to make some workflow from the first solution and keep using scale with screen size, it would require specifying each measurement field during UI creation by referencing custom uss properties like 4dp, 8dp, etc., and then setting the styles with proper dimensions in actual pixels per screen density via script in runtime.

1. What would you suggest doing in such cases, so that scrolling deceleration is smooth when UI is upscaling?
2. Are there any plans for the feature that would let users specify dimensions in constant physical size in addition to pixels or are there any updates planned for ScrollView?
3. Are you planning on making some recommendations to adaptive UI workflows with the current state?

[SimonDufour]

First time I am personally looking at the relation between scroll speed and screen scaling of game UI. I assuming by now we do the right thing in the editor but I must agree we have overlooked the precision of the runtime scroll. Usually the scrolling on mobile is done using touch events so there less consideration for scroll wheel sensitivity for theses platform.

The ConstantPhysicalSize and scaling in general was derived from concepts coming from UGUI but the behaviors need to be reworked in the future. Most notably, I don’t think the code ever look at the real dpi of the screen. ConstantPhysicalSize just provide a different scaling method based on a dpi value that the user should provide if I remember correctly.

You should not try to scale your UI to get proper scroll values. I would go the other way, just make the ui what you want it to be and then set the scroll speed using the attributes and variables:
Scrollview.mouseWheelScrollSize = for mouse speed and
:root { --unity-metrics-single_line-height: 500px; } to override the default line height.

Overall, the deceleration and scroll speed for both mouse and trackpad are controlled by the os and adjustable by the user. They may occurs in “line number” or as some float amount of pixel depending on the input (precision trackpad usually are in float values, while mouse click are in number of lines) If you look at you game and a native window, a scrolling input of the same speed/length should result in the same displacement in any scrollview. The only exception to this is if you are attempting to scroll by a full page at a time. If it is not the case by default you can report a bug and mention this thread.

I would say there could be some legacy behavior that did not consider screen dpi in there

Unity-Technologies/UnityCsReference/blob/79868d37d65d6efb5196aaf002f97a6f87b22f97/Modules/UIElements/Core/Controls/ScrollView.cs#L1723

We did some improvement and fixes over the pasts months for the scrolling behavior (notably removing the artificial 30fpps limitation) and we are looking to improve the anything we can. I think allowing different kind of unit for the scaling is unfortunately out of line with our current priority but you suggest it be added to our roadmap.

[SimonDufour]

We internally have a bug already opened that note the scaling behavior between the ui builder preview mode and play mode is different. I am supplementing the bug with a link to this thread.

[nz2develop]

@SimonDufour

You should not try to scale your UI to get proper scroll values. I would go the other way, just make the ui what you want it to be and then set the scroll speed using the attributes and variables:
Scrollview.mouseWheelScrollSize = for mouse speed and
:root { --unity-metrics-single_line-height: 500px; } to override the default line height.

Btw, I’m using Unity 2022.3f20 on macOS.

What about scrolling via touch screen? seems that the --unity-metrics-single_line-height is not related to that.
https://github.com/Unity-Technologies/UnityCsReference/blob/37a24de7ee24e5a20b9e8fc85e5e28f0b218b8c9/ModuleOverrides/com.unity.ui/Core/Controls/ScrollView.cs#L1434
https://github.com/Unity-Technologies/UnityCsReference/blob/37a24de7ee24e5a20b9e8fc85e5e28f0b218b8c9/ModuleOverrides/com.unity.ui/Core/Controls/ScrollView.cs#L1269

The velocity there is not multiplied by any scale or dpi factor before updating the offset.
And that’s actually where the problem occurs for me, during inertia scrolling on iOS devices.

[SimonDufour]

I think there is a velocity/deceleration attribute in the scrollview.

[nz2develop]

@SimonDufour

First time I am personally looking at the relation between scroll speed and screen scaling of game UI. I assuming by now we do the right thing in the editor but I must agree we have overlooked the precision of the runtime scroll. Usually the scrolling on mobile is done using touch events so there less consideration for scroll wheel sensitivity for theses platform.
…
I would say there could be some legacy behavior that did not consider screen dpi in there

Is this the API you were talking about? GUIUtiliti.RoundToPixelGrid(float) https://github.com/Unity-Technologies/UnityCsReference/blob/37a24de7ee24e5a20b9e8fc85e5e28f0b218b8c9/ModuleOverrides/com.unity.ui/Core/Controls/ScrollView.cs#L571

Because changing the deceleration rate doesn’t affect the “smoothness”, there is still “snapping” of scroll offsets

[SimonDufour]

@nz2develop

Is this the API you were talking about?

no,i was thinking of the scroll-deceleration-rate
In the manual and in the scriptReference

• elasticity

• mouse-wheel-scroll-size

• scroll-deceleration-rate

• touchScrollBehavior

I think if you set a deceleration rate of 0 and still have any “velocity” occurring they are generated by the os.

[nz2develop]

@SimonDufour

I think if you set a deceleration rate of 0 and still have any “velocity” occurring they are generated by the os.

setting the deceleration rate to 0 results in a full stop, e.g. no velocity. and setting it to 1, results in a constant but also smooth scroll, even if the drag is subtle, and the resulting velocity is small.

and btw, it also occurs and can be reproduced in Unity’s device simulator.

So you mentioned that you’ve opened a bug report internally, so the problem is known or do you need some additional info from me?

[SimonDufour]

There was a bug open to reconsider what we are doing with scroll event, but it had a much wider scope than what you suggested. I added a note for your actual considerations and link to this thread in the bug report.

But your bug is much smaller than the scope of the existing one. I already talked with a dev and it seems we could do a small patch while waiting for the larger rewrite. Worst case is the proper team will mark it as a duplicate.

[nz2develop]

Great to hear that, thanks for clarifications
If it’s possible, could you please send me a link where I can track updates on this bug/issue?
Or should I start checking patch notes related to UI Toolkit and ScrollView in general?