You are not logged in.

1

Tuesday, October 16th 2018, 3:37pm

Load panorama without any delay, using preview !!!

Hello!

My question is simple. Is possible prevent from 1-2 sec delay while preview pano is swapping to original pano?? Currently, on the begin, preview pano is loading, next when original pano has been downloaded krpano is swapping panos from preview to original (pano || content) with 1 or 2 sec LAG (user interface is frozen). Is any solution exist to eliminate lag??

Greetings!

This post has been edited 2 times, last edit by "rejentt" (Oct 17th 2018, 1:36pm)


2

Wednesday, October 17th 2018, 1:38pm

Klaus any suggestions?

Greetings!

3

Saturday, October 20th 2018, 7:58am

Hi,

you might mean the time the browser requires for the image-decoding and the time it needs for uploading the image to the GPU.
Both operations are running the browsers main-thread and blocking there the whole page.

The best solution for this would be using multi-resolution images.

Best regards,
Klaus

4

Sunday, October 21st 2018, 9:40am

Thank you Klaus for you answer!


I wonder if there is a possibility to write a krpano plugin which will decode and load img to GPU using Promis,
but this would involve obtaining a sphere object on which texture is loaded. And question, is possibility to get into this sphere object? I tried use krpano webgl context inside three.js but I could not make it.


Thanks, and i hoping for your answer again ;)

5

Sunday, October 21st 2018, 6:32pm

Hi,

using Javascript Promises doesn't help in any way, they are also just running on the main-thread and don't help on heavy browser API operations.

But for the next krpano release I have already implemented an optional the usage of worker-threads and the createImageBitmap API to avoid that the main-thread gets blocked during image-decoding. But the image-to-gpu uploading is still only possible on the main-thread, that's the faster parts of these two operations.

But these APIs are currently only available in Chrome and Firefox, not on iOS yet - and they would only avoid a blocking of the user-control/user-interface during the image-decoding. The 'delay' itself (=the time between having loaded that data and having the image on the screen) is caused by the time the CPU needs to decode the image, can't be avoided of course. To make that quicker only smaller images (e.g. multires) helps.

Best regards,
Klaus

6

Tuesday, October 23rd 2018, 9:08am

Thank you for reply. You are doing a great job! :)