I am looking for ways to improve FPS on this sandcastle application:
When I pan or tilt on fullHD or higher resolution display, the FPS drops below 20 FPS and the app starts to feel laggy. It seems that the presence of 3D tiles and geodata does not have much influence on this behavior. Are there some ways or parameters that could make this better? E.g. like
requestRenderMode : true which makes CesiumJS consume less resources when still?
Or may there be some different issue that causes the FPS to drop?
Env: Ubuntu 16.04, chromium-browser 72.0
RequestRenderMode will help but only when nothing in view is changing.
If you just resize the window to make it smaller, does FPS go up on the same view? To confirm it’s a problem of resolution, try lowering the viewer resolution scale:
viewer.resolutionScale = 0.5;
This will make it render at half the size and scale the canvas up. It won’t look as good but it should improve performance. Let me know if that helps.
You could also tweak the terrain/imagery’s screen space error, since it might be loading too many tiles at this resolution:
viewer.scene.globe.maximumScreenSpaceError = 4; // Defaults to 2
You can do the same thing for your 3D Tiles:
tileset.maximumScreenSpaceError = 32; // Defaults to 16
I don’t know for Ubuntu, but in Windows, while rendering a heavy webgl page, Chrome doesn’t automatically turn to graphic cards, it still use integrated graphic cards, with cause a unacceptable low FPS.
Only force Chrome to be rendered in external graphic cards, for example in nvidia control panel, then it respond correctly and get 60FPS for most pages.
在 2019年3月22日星期五 UTC+8上午1:08:07，Ladislav Horký写道：
Karl: thanks for the advice, but this seems not to be an issue, I will keep an eye on that to be sure but so far I have run it on desktops with dedicated GPU with the same result. According to nvidia-smi, the chrome consumed memory on the GPU so I assume it used the dedicated one. It also seems not directly related to GPU power - it behaves similarly on GTX1060 and GTX630 (many classes and years appart). It may be, however, influenced by WebGL implementation in given browser.
Omar: thanks for the tips. the
viewer.resolutionScale = 0.5; helps a bit - the FPS raises by about 50% to around 30 (from slightly below 20).
It seems that this parameter (logically) influences how coarse data will be used so I would expect bigger effect if this was purely rendering/webgl related issue. I will try experimenting with max screenspace error for the terrain but I expect the result may be similar.
I have one more related question about performance and geodata. When I load 17M GeoJSON with parcel data, it does not have direct influence the performance but I notice the the CPU usage goes up to 90% even when idle. I have
requestRenderMode = true. When profiling, the culprit seem to be some long
upadate of something within the
tick function. Can I set something on vector entities to lower the CPU usage? Maybe delete some callback that is there by default?
Also, is it possible to load the geodata on background to overcome the loading lag?
This example will be part of talk on performance comparison between Cesium and VTS held in San Diego. There is a github-pages repo for that: ladislavhorky/battle-of-3d-rendering-stacks - if you are willing to check it out, any feedback would be most welcome. The terrain may not be visible because it is now served from a local server but this will be fixed.
út 2. 4. 2019 v 3:42 odesílatel Karl Tian firstname.lastname@example.org napsal:
This project looks super cool! I actually be in San Diego next week for FOSS4G, I’m definitely going to come to your talk! I’m very curious to hear the results of this benchmark.
In terms of requestRenderMode, it does seem like any entity with a dynamic property essentially forces requestRenderMode off, I posted a bit about it here and suggestions on solutions: https://github.com/AnalyticalGraphicsInc/cesium/issues/6631#issuecomment-461835478
I’m not sure off the top of my head how to easily find which entity(ies) have dynamic properties. For loading the GeoJSON data in the background, this is actually one of the oldest still-open pull requests in Cesium:
It was never merged because of a lack of consensus on how best to implement this. You could try merging that fix in to a fork, but I’m not sure if it would require a lot of work to bring it up to the current version. The long term solution to this is to develop the 3D Tiles vector format, and tile this vector data so it loads in seamlessly regardless of how big it is.
looking forward to see you there! Regarding the dynamic properties I think I get the idea. I tried disabling distance condition on labels (the only thing that looks dynamic), just in case it would be that trivial but it really is deeper. I think we can discuss this and possibly other optimizations on the spot if you are OK with it.
The vectors in 3D Tiles you mention look like a final solution indeed.
čt 11. 4. 2019 v 23:30 odesílatel Omar Shehata email@example.com napsal: