Browsers limit the number of active webgl contexts on a page; for chrome it's 16. Each rdeck map uses 2 webgl contexts (if using a basemap); this limits us to 8 rdeck maps per html report, which is a lot, but this is occasionally a barrier.
It is unlikely that more than 8 maps could be visible at one time on a html report, so this limit is only imposed due to eagerly loading rdeck widgets. If maps could be optionally rendered when they're scrolled into view, we can effectively have no limit to the number of maps we can add to a report.
Performance trade-off
Lazy loading of maps would result in some rendering lag when they become visible, because they're being re-initialised. However, a report with lazily loaded maps that are initially not visible should render faster than an identical report with eagerly loaded maps.
anthonynorth
commented
1 year ago
Browsers limit the number of active webgl contexts on a page; for chrome it's 16. Each rdeck map uses 2 webgl contexts (if using a basemap); this limits us to 8 rdeck maps per html report, which is a lot, but this is occasionally a barrier.
It is unlikely that more than 8 maps could be visible at one time on a html report, so this limit is only imposed due to eagerly loading rdeck widgets. If maps could be optionally rendered when they're scrolled into view, we can effectively have no limit to the number of maps we can add to a report.
Performance trade-off
Lazy loading of maps would result in some rendering lag when they become visible, because they're being re-initialised. However, a report with lazily loaded maps that are initially not visible should render faster than an identical report with eagerly loaded maps.