Skip to content
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

Honor windows.devicePixelRatio by default #3233

Merged
merged 2 commits into from
Nov 21, 2015
Merged

Honor windows.devicePixelRatio by default #3233

merged 2 commits into from
Nov 21, 2015

Conversation

mramato
Copy link
Contributor

@mramato mramato commented Nov 21, 2015

Honor windows.devicePixelRatio by default

Way back in #1162 (over two years ago), we put in changes to let Cesium render at native screen resolution, ignoring window.devicePixelRatio. This made sense at the time because

  1. A lot of mobile devices would end up rendering at 320x240 and look horrible.
  2. 4K screens were would render at 1920x1080 instead of 4K (and 4K was rare and everyone that had one had powerful hardware to go along with it.

The above reasons no longer make sense

  1. Mobile screens have crazy resolutions now (for example my phone is 2560 x 1440), but many don't have the GPU to render WebGL at that resolution. When we honor the DPI setting, we are still rendering at a high resolution (in this case 1280 x 720) and there's no noticeable difference in visual quality because of the small screen size. On my phone this brings a blank Viewer from 15fps to 60fps.
  2. 4K and high DPI displays are everywhere (especially on Mac) but a lot of those machines can't render WebGL anywhere near 60fps at 4k. Similar performance gains will happen for these devices.

Finally, this also greatly reduces bandwidth when devicePixelRatio > 1 because we are sucking down way less terrain and imagery tiles. This is another huge improvement for mobile.

Cesium now honors `window.devicePixelRatio` by default, which greatly
improving performance on mobile devices and high DPI displays by rendering
at the browser-recommended resolution.

This change also decreases bandwidth usage because we request far fewer
tiles when rendering at lower resolutions.
@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 21, 2015

Looks good.

pjcozzi added a commit that referenced this pull request Nov 21, 2015
Honor windows.devicePixelRatio by default
@pjcozzi pjcozzi merged commit b7ca35b into master Nov 21, 2015
@pjcozzi pjcozzi deleted the dpi branch November 21, 2015 18:43
mramato added a commit that referenced this pull request Nov 28, 2015
As @kring pointed out in #3249, my code in #3233 was actually wrong and
caused increased resolution loss when `window.devicePixelRatio` was greater
than 1.  We should just be ignoring `window.devicePixelRatio` completely
because the browser takes care of it by default.
mramato added a commit that referenced this pull request Dec 3, 2015
This reintroduces #3233, but now uses the `image-rendering` CSS property
to disable smooth scaling and avoid burriness. Since this is a CSS4
property, it's not supported by all browsers (Safari/IE), so we detect
if the property is supported and if it isn't, we fallback to full
resolution rendering on those browsers so that the image is always crisp.
mramato added a commit that referenced this pull request Dec 4, 2015
This reintroduces #3233, but now uses the `image-rendering` CSS property
to disable smooth scaling and avoid burriness. Since this is a CSS4
property, it's not yet supported by all browsers (Safari/IE), so we detect
if the property is supported and if it isn't, we fallback to full
resolution rendering on those browsers so that the image is always crisp.

The other nice thing about this approach is that it's detect capability
and not the browser itself, so when Safari and IE do add support, Cesium
will automatically start taking advantage of it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants