mapillary
Image tiling performance improvements and device support
The current implementation of image tiling is creating a texture with the size of the original image. This is memory inefficient for large images, e.g. panoramas with sizes up to 16384 x 8192 px, and causes long rendering times leaving the viewer unresponsive for up to hundreds of milliseconds from time to time. On devices where the WebGL max texture size is smaller than the original image size the texture will just be scaled and it will not be possible to view the full resolution even when zooming.
The idea with this issue is to only create a texture with the amount of pixels that is needed for the current viewport size. That reduces the memory requirements, the WebGL max texture size will not be a limiting factor, the rendering speed will be improved, and the viewer should behave more smoothly when panning/tilting/zooming.
Interestingly enough, I have also stumbled upon this and it causes real issues on some hardware, not just performance but breaks functionality. You cannot zoom in fully if GL_MAX_TEXTURE_SIZE is smaller than an image in one dimension. So, maybe it is about time to fix it. :wink:
See here:
| Zoom level | GL_MAX_TEXTURE_SIZE | |
|---|---|---|
| 2 | 16384 | 4096 |
|
|
| |
The idea with this issue is to only create a texture with the amount of pixels that is needed for the current viewport size.
For what it’s worth; sure, you can do this but it is complicated to compute the size, shape, and texture coordinates of the needed texture, especially when dealing with multiple projections. And, what do you do if the viewport is larger than GL_MAX_TEXTURE_SIZE? Imho the simplest way would be to just split the image either evenly or unevenly over multiple textures and always render all textures, even those not in view. It may not be as performant as rendering only one texture but you would not need to create a texture for every frame when animating (zooming in/out), unless you intend to create the texture only after animation has stopped. Besides, since OpenGL ES 2.0, all hardware renderers are very good at rendering of at least 8 or more textures in series and in parallel (you just have to bind to all texture units). And, most older renders can deal with multiple parallel textures just fine too.