Performance of cropped panorama display
Opened this issue · 4 comments
Describe the feature
After a bit of testing, I found that the loading of a cropped panorama tends to be slower compared to a non-cropped panorama. If a picture is already loaded once (in cache), pure loading of panorama is instant for non-cropped, and around a second for cropped. I don't know until which point cropped panorama performance can be improved to be comparable to non-cropped.
Alternatives you've considered
No response
Additional context
A demo with PSV 5.7.2, on this area you have both classic 360° panorama (green line on map) and flat pictures inserted as cropped panorama (yellow line on map). If you go back and forth on images, they land in cache and then you can see performance difference between both cases.
You test on Firefox right ? I experience some stuttering on FF, but on Chrome the loading is instantaneous.
Also how exactly to you display cropped panoramas ? I remember your are using the tiles adapter with a full-res base pano and no tiles, is it right ?
I that case you are comparing the loading of a "large" cropped image and the loading of the low resolution base image.
Currently the cache is at the loader level, it contains the Image/Blob resulting of the HTTP request, perhaps it could be modified to store the final texture once it has been computed.
Tested on Firefox 124 and Chromium 123, I confirm this is better under Chromium.
Cropped panoramas are shown using Equirectangular Tiles adapter, with base pano in standard definition (2048px wide, for both 360° or classic images). 360° have tiles, classic have not (URL function returns null). So beyond tile loading (which happens after), base pano loading is on similar files (in example, classic ~250ko, 360° ~400ko).
Caching computed texture would help on second loading for sure.
I am afraid caching the file texture is much more complicated than expected. It is assuming the "panoData" is already correct, but it is not the case when the panorama is preloaded, XMP data are loaded but potential "panoData" overloaded in the virtual tour node (or anywhere else) are not.
By caching only the original image I am sure that the final texture is always correct according to the current configuration.
And the modification cascades very deeply in all adapters, I fear some bad regressions.
If something has to be done it is optimizing the canvas operations, but I have no idea why Chromium is better than Firefox here.
Thanks for taking time investigating in this issue, if the issue is browser-side there is for sure not much to do in PSV to solve this 😅