Too many tiles requested by imagery layer leads to poor performance
- Dominant language
- JavaScript
- Stars
- 15.8k
- Forks
- 3.9k
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 34
Description
Hi, guys!
Some time ago we decided to replace NASA World Wind working as Java Applet in browser by Cesium in order to display multiple imagery layers (I mentioned it in #2047). Our application allows a user to specify filter parameters (such as time range, geographic region, satellites, sensors and type of products of interest) and display found raster data (set of segments grouped by orbits) on the globe. I overlay each orbit of processed data as a separate imagery layer. To demonstrate it here is a screenshot of the application:

Initially plain WMS was used to send imagery tiles but in order to increase performance we are switched to WMTS. Unfortunately, it helped a little. I started to look at source code and found that some work to choose tiles for rendering is done [here](https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/QuadtreePrimitive.js#L387). It's very difficult to understand what's going on there at a glance but I stated that many tiles starting from zero level of detail up to current level of detail are analyzed and prepared for requesting/rendering constantly in short time interval. Probably, something is wrong with detection of which tiles on lower-detail levels should be used 'cause, for example, when I enable imagery layer on 7th level of detail I see a lot of tile requests (at least 250-300), and most of them are empty (they are outside of current viewport):

If I enable all imagery layers per page (no more than 20) and zoom in I end up with browser hanging...I guess, that all these things happen in main JavaScript thread, and there are too many tiles! This fact seriously limits Cesium application in our case that's why I open the issue.
I look at [terrain and imagery roadmap](https://github.com/AnalyticalGraphicsInc/cesium/issues/526), but didn't find anything related to this there.
What can we do? Any ideas? Do you plan, guys, some improvements on this? Is it possible to use some another algorithm to filter tiles (is it called culling?), probably, to skip some levels of detail (even all excepting the current one) or improve existing algorithms by limiting to only really visible tiles (which are in viewport and are not covered by tiles of other imagery layers).
I'm also ready to try to do something but don't know where to start. Is there any tutorial describing in details how imagery layers are loaded?
Contributor guide
Research direction
Start with Source/Scene/QuadtreePrimitive.js around the tile-selection logic linked in the issue, then reproduce the behavior with multiple imagery layers and increasing zoom levels. Measure the requested tiles and browser responsiveness, especially the reported 250–300 requests and hangs. Done would require a clearly defined reduction in unnecessary requests or rendering work without breaking visible imagery.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend, performance
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100