my pano website went nuts - jumping tiles.

  • Good moning Klaus, and all

    You're the man!

    I came here and wrote this because i get this on my home pc and asked if anyone saw the same in the Facebook Panoramic Photographers group... and someone did...

    i'm on a windows pc

    in fact, here, at work, using 1.19pr6, windows 10, chrome 52.0 webgl i don't have "tile swap" i experience at home .. just a tiny jump at end of little planet intro but thats not it (most people wont notice it and does not matter)

    i'll post my home configuration today by donner time.

    Thank you so much for your time.

  • hi

    at home i got windows 10
    krpano 1.19pr6
    chrome 52.0
    the player says html5/Desktop webGl

    Notice the compass on the screenshots same FOV, same heading, very different image
    It does not rotate left or right.. it jumps (a lot) up and down its ok.. normal...

    In firefox 37.0 it's ok.. runs smoothly on every direction.

    Thank you for your time.

  • Hi,

    first - that's an insane bug of the Chrome 52 browser!
    (but I've found a workaround, more below)

    Details and internals about that bug:

    In my own tests with Chrome 52 on several Windows systems that bug wasn't happening, but yesterday coincidentally I was testing krpano with Electron 1.3.4, which is also based on Chrome 52, and there I was able to see that bug too - the pano view was jumping crazy around and seems to be locked somehow at some specific horizontally positions... extremely strange and basically impossible to happen!

    After a lot of debugging I could finally lock down the problem to one simple code line in the WebGL rendering part of the viewer:

    var h = panoview.h;

    That's very simple Javascript code - it defines a variable named 'h' and copies the the value of the variable 'panoview.h' to it.

    I have simply logged that these variables this way:

    var h = panoview.h;
    console.log("h="+h+" panoview.h="+panoview.h);

    and got this output when panning around:

    Have a look at the 'h' values!

    That means after some rendering frames the value of the 'h' variables gets crazy!
    But that's impossible - 'h' and 'panoview.h' would need to be always the same!

    I have checked everything around, there is no code bug, no external influence or anything else! For some reason the browser simply sets wrong values in the 'h' variable. And so in all further rendering steps that wrong value for the viewing position was used.

    After some web-research I found that other developers also had strange problems with Chrome 52 - e.g. here two reports:…-52/swizec/6908…out_this_crazy/

    That means something fundamentally is broken in Chrome 52 (and Chrome 51 might be affected as well).

    But there is also a good thing - in Chrome 53, which was released yesterday, that bug seems to be fixed. That means as first step please try updating your Chrome browser (e.g. by checking its help menu).

    Additionally I have tried working around that bug by slightly modifying the code and that also seems to work, but a browser with such bugs can't be really trusted... other strange things could happen also somewhere else...

    Anyway - here also an updated krpano viewer for testing. There this Chrome bug shouldn't occur anymore. That workaround will be also included in the next krpano release:

    Best regards,

  • that stupid chrome bug caused a lot of work as it seems...
    i just use a fov zoom intro instead of a little planet intro for chrome v52
    from what u write i guess v52 will not be safe anyway.

    ps. nwjs is on chromium v53 now, too

    and... thanks for all your work on that!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!