CesiumGS / CesiumGS/cesium

Too many tiles requested by imagery layer leads to poor performance

Open
#3,857 21 comments 3 reactions 0 assignees View on GitHub
category - 3d tiles category - terrain and imagery type - enhancement
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:

![geoport-data](https://cloud.githubusercontent.com/assets/665479/14570367/8f049e1e-034c-11e6-9bac-729b3b6b48c3.png)

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):

![out2 3](https://cloud.githubusercontent.com/assets/665479/14572394/49d911fc-0357-11e6-8a5c-18769115b7a0.gif)

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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.