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

Performance regression between 1.113 and 1.114 #11811

Closed
javagl opened this issue Feb 5, 2024 · 2 comments · Fixed by #11829
Closed

Performance regression between 1.113 and 1.114 #11811

javagl opened this issue Feb 5, 2024 · 2 comments · Fixed by #11829

Comments

@javagl
Copy link
Contributor

javagl commented Feb 5, 2024

There seems to be a performance regression in 1.114 compared to the previous version.

What I tested with 1.113 and 1.114:

  • Run npm run start locally
  • Open the "OSM Buildings" Sandcastle on localhost
  • Add viewer.scene.debugShowFramesPerSecond = true; to show the FPS
  • Zoom in and out a bit with the mouse wheel.

With 1.113, the FPS remains basically constant at 59.
With 1.114, the FPS drops to 4 ... 10 while zooming. (When not zooming, it goes back to 59)

This is apparently related to the new Screen Space Controller behavior that was implemented with #11581 . When creating the OSM buildings tileset with

const osmBuildingsTileset = await Cesium.createOsmBuildingsAsync({
  disableCollision: true
});

then the FPS remains 59 even with version 1.114.

(I have not yet extensively tested it with other tilesets. Things like the Google P3DT do not seem to be affected so noticably, although a dedicated analysis (whether ~"the average FPS dropped by 5%" or so) could be difficult...)


EDIT: This might be one of the few cases where some system information might be relevant (at least more than in other cases). This was tested on Windows 10, with an NVIDIA GeForce RTX 2070, on the latest Chrome and FireFox.

@jjspace
Copy link
Contributor

jjspace commented Feb 5, 2024

Possibly related to #11787

@ggetz
Copy link
Contributor

ggetz commented Feb 7, 2024

I'm looking at this now. Basically, we were using bounding spheres rather than the bounding volumes to pre-optimize picking on tilesets. I'm working on the ray volume intersection logic and will have a PR open soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants