-
-
Notifications
You must be signed in to change notification settings - Fork 630
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance of cropped panorama display #1278
Comments
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 😅 |
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.
https://files.pavie.info/clients/panoramax/next_ui/#background=streets&focus=pic&map=18.63/48.3247814/-1.9500714&pic=be67e961-3915-44c4-aefd-6b87cbce5a0c&speed=250&theme=type&xyz=77.00/0.00/30
The text was updated successfully, but these errors were encountered: