Performance of cropped panorama display about photo-sphere-viewer HOT 4 OPEN

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.

from photo-sphere-viewer.

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.

from photo-sphere-viewer.

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.

from photo-sphere-viewer.

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 😅

from photo-sphere-viewer.