I have generated a local tileset which I call with
var viewer = new Cesium.Viewer('cesiumContainer', {
imageryProvider : Cesium.createTileMapServiceImageryProvider({
url : Cesium.buildModuleUrl('Assets/Textures/BlueMarble'),
tileWidth: 2700,
tileHeight: 2700
}),
}
There are 3 levels, each tile is 2700 x 2700 px in jpg.
Each time a new tile is loading, the rendering stops until it is fully loaded, that's about 800 ms. I believe there is no such limitation when using WMS tiles (a refinement does not block rendering).
Is there any way to avoid that and to keep rendering while a new tile coming from a local file is loading?
When you say rendering stops, do you mean the render loop blocks (so you can’t move/interact with the viewer)? Or does the imagery flicker/disappear during that time? Either way, I think it isn’t expected behavior and something we might want to look at it.
My first guess is it might be that the tiles are too big. Can you try tiling it to tiles that are smaller? You could also try uploading your imagery to ion (https://cesium.com/ion/) and use its tiling just to compare performance. Let me know what you find out.
Thanks for following up. I’m in the case where the render loop stops so that I can’t interact with the viewer. For sure, the tiles are quite big (2700 x 2700 px). Instead of reducing there size, I’d like to understand why this occurs, in order to achieve more robustness.
I tried to upload my imagery files on Ion, but as they are not natively georeferenced (8 JPG files), they don’t seem to be compatible with Ion.
I uploaded my assets here (https://we.tl/t-8fIYJLWdhN), can you try on your side to see what’s happening?
It was easier to see the hiccup when the camera flies through. Were you doing something like that when you ran into this? It feels a lot less shorter than 800 ms but that could just be my machine.
The last line there also turns on the Cesium inspector, which lets you visualize which tiles are loaded (click “Terrain” and then “Show tile coordinates”) which might help.
I’m not sure at a glance what’s causing this. If you put a break point on ImageryProvider.js’s load image function with Chrome’s debugger:
And you can follow it see that it should all be asynchronous. The Resource.js’s fetchImage function might also be another good place to look.
If you find out any more please continue to update this thread. I hope this helps a bit.
I’ve been profiling exactly what’s causing the hiccup, and the picture below tells that each time a new tile (2700 x 2700 px, 1 to 5 MB each) is loaded, the painting subroutine takes 40 to 100 ms of CPU and blocks the render loop.
I have checked that this calculation time is independant from the size of the image file (by reducing the JPEG quality), it is mainly related to the number of pixels of the image.
One solution would definitely be to load smaller tiles. But that shows that the process of tile loading is not fully asynchronous as it should be, right?
Thanks for the detailed profiling report Dorian! This sounds like the browser itself is the bottleneck here. I found this Chrome issue about the speed of texImage2D:
I think what’s happening is, WebGL calls execute in the same thread as JavaScript, so I think that’s why an expensive WebGL call freezes the context. So every time a new tile comes in, it’s drawing it to the screen that takes so long. Even if it’s just for loading, I think sometimes Cesium has to do extra steps, so for example here a texture has to be converted into a power of two texture so that’s an extra draw call:
