You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working to have Cesium render at the browsers native resolution (#7875) density it became apparent that there was a bigger design change required. Here are some the changes I plan to bring in a pull request soon (since they are highly related)
Decouple SSE from Cesium's Resolutions
Problem
Currently, if the user sets the resolution scale to x2 the SSE will be effected as well. It is outside a users expectation for a change in resolution to also impact SSE. Here is an example:
resolutionScale used to be a constant 1 that could be changed by the user but now it's set to window.devicePixelRatio by default.
resolutionScale = 1
resolutionScale = 2
resolutionScale = 2
maximumScreenSpaceError * viewer.resolutionScale
When the user sets the resolutionScale to 2 it nearly triples the amount of tiles loaded. The only thing resolutionScale should do is increase resolution instead of inadvertently impacting SSE.
Solution
The way to fix this is take the resolutions scaling factor and multiply SSE by that factor. When resolution changes SSE stays constant. (Much like the example I provided in the third quadrant of the table) This would involve passing a resolutionScale to FrameState and making resolutionScale a part of the Scene.
Resolution Scales With Device Pixel Ratio
Cesium should render at the same pixel ratio as the window.devicePixelRatio but as Ed pointed out:
But this isn't resolutionScale, it's devicePixelRatio. The latter is affected by things such as CTRL + and CTRL - screen scaling, and Windows Desktop DPI scaling. Just for completeness, has someone tested the effects of those being set to non-default settings?
Me an @lilleyse agreed when talking privately most users would prefer to see an equally high resolution image of cesium when zooming in than degraded image. So instead of passing devixePixelRatio as the default resolution scale we create a resolution final resolution scale that is: resolutionScale * devicePixelRatio.
Please feel free to provide feedback.
The text was updated successfully, but these errors were encountered:
When working to have Cesium render at the browsers native resolution (#7875) density it became apparent that there was a bigger design change required. Here are some the changes I plan to bring in a pull request soon (since they are highly related)
Decouple SSE from Cesium's Resolutions
Problem
Currently, if the user sets the resolution scale to x2 the SSE will be effected as well. It is outside a users expectation for a change in resolution to also impact SSE. Here is an example:
resolutionScale
used to be a constant 1 that could be changed by the user but now it's set towindow.devicePixelRatio
by default.resolutionScale = 1
resolutionScale = 2
resolutionScale = 2
maximumScreenSpaceError * viewer.resolutionScale
When the user sets the
resolutionScale
to2
it nearly triples the amount of tiles loaded. The only thingresolutionScale
should do is increase resolution instead of inadvertently impacting SSE.Solution
The way to fix this is take the resolutions scaling factor and multiply SSE by that factor. When resolution changes SSE stays constant. (Much like the example I provided in the third quadrant of the table) This would involve passing a
resolutionScale
toFrameState
and makingresolutionScale
a part of the Scene.Resolution Scales With Device Pixel Ratio
Cesium should render at the same pixel ratio as the
window.devicePixelRatio
but as Ed pointed out:Me an @lilleyse agreed when talking privately most users would prefer to see an equally high resolution image of cesium when zooming in than degraded image. So instead of passing devixePixelRatio as the default resolution scale we create a resolution final resolution scale that is:
resolutionScale * devicePixelRatio
.Please feel free to provide feedback.
The text was updated successfully, but these errors were encountered: