We have a getTileData and a renderTile callback in our RasterTileLayer-based layers.
The idea is that getTileData should be able to run only once to do all fetching to create resources, while renderTile might change on every frame (such as for an animation).
In deck.gl the TileLayer caching stores the result of getTileData. This means that if you return Texture objects from getTileData, and you use the default TileLayer caching (maxCacheSize, which defaults to 5 times the number of tiles in the current viewport), then you have to know you're storing all the data in GPU memory, and you might hit user limits on available GPU memory.
So either we should split the CPU caching from GPU caching... or I'm not sure?
I think it's recommended behavior to return GPU textures from getTileData? It might not be in the upstream case where there's some default caching in the render flow of texture creation...
We have a
getTileDataand arenderTilecallback in our RasterTileLayer-based layers.The idea is that
getTileDatashould be able to run only once to do all fetching to create resources, whilerenderTilemight change on every frame (such as for an animation).In deck.gl the
TileLayercaching stores the result ofgetTileData. This means that if you returnTextureobjects fromgetTileData, and you use the defaultTileLayercaching (maxCacheSize, which defaults to 5 times the number of tiles in the current viewport), then you have to know you're storing all the data in GPU memory, and you might hit user limits on available GPU memory.So either we should split the CPU caching from GPU caching... or I'm not sure?
I think it's recommended behavior to return GPU textures from
getTileData? It might not be in the upstream case where there's some default caching in the render flow of texture creation...