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

Default to high performance context option? #8543

Closed
mramato opened this issue Jan 15, 2020 · 1 comment · Fixed by #8548
Closed

Default to high performance context option? #8543

mramato opened this issue Jan 15, 2020 · 1 comment · Fixed by #8548

Comments

@mramato
Copy link
Contributor

mramato commented Jan 15, 2020

Via Ken Russel and the webgl mailing list: CC @lilleyse

A change is forthcoming in the Chrome browser which only affects dual-GPU MacBook Pros right now, but may affect dual-GPU Windows laptops in the near future.

Chrome used to treat WebGL's "default" powerPreference context creation option as "high-performance". In Chrome 80, in order to save battery life and improve the user experience on these dual-GPU machines, the default has been changed to "low-power". Note that Safari on macOS has had this behavior for some time now.

Applications with computationally expensive shaders, complex geometry, or which approach peak GPU utilization may want to explicitly specify the 'high-performance' powerPreference during WebGL context creation. Note that this carries a user experience cost, as switching between the integrated and discrete GPUs causes the system to stutter for ~1 second.

Note also that Chrome will deliver context lost notifications more often upon GPU switches, when it determines that OpenGL resources couldn't be automatically migrated between GPUs. (Multisampled renderbuffers, in particular, are subject to this limitation - and this will likely apply to all operating systems.) Please use the WEBGL_lose_context extension to ensure that your applications are robust to context loss and restored events; see Handling Context Loss on the WebGL wiki.

Users can already do this themselves by passing contextOptions when creating the Viewer, but should Cesium default to high performance mode explicitly unless told otherwise? Or do we just use the browser default and let the apps decide if they need the extra juice?

I'm not sure how I feel, I can see either way.

@kring
Copy link
Member

kring commented Jan 15, 2020

We should default to fast, but allow it to be overridden. Because:

  • That will create a more positive first impression of Cesium.
  • Most apps will need it. Cesium is not very fast on integrated CPUs. ☹️
  • In my experience, battery life isn't too terrible even when running on the discrete GPU full time.

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 a pull request may close this issue.

2 participants