Sie sind nicht angemeldet.

1

Dienstag, 16. Oktober 2018, 15:37

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!

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »rejentt« (17. Oktober 2018, 13:36)


2

Mittwoch, 17. Oktober 2018, 13:38

Klaus any suggestions?

Greetings!

3

Samstag, 20. Oktober 2018, 07:58

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

Sonntag, 21. Oktober 2018, 09:40

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

Sonntag, 21. Oktober 2018, 18:32

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

Dienstag, 23. Oktober 2018, 09:08

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