You are not logged in.

Dear visitor, welcome to krpano.com Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

herrpedro

Trainee

  • "herrpedro" started this thread

Posts: 134

Location: Lisbon

Occupation: Programmer/analyst

  • Send private message

1

Sunday, August 28th 2016, 10:55pm

my pano website went nuts - jumping tiles.

was having issues in pr4.. i think i did not have them in pr3

upgraded it from pr4 to pr6 and still the same

i got jumping tiles all over
my xml generator is the same a while ago.. may be it has some setting that does this?
anyone knows wich one might be?

http://www.panoramapalace.com/p/viewpano…ed-87c4a36c6de1

thank you all for your time.

Rui Pedro

2

Tuesday, August 30th 2016, 9:33am

Hi,

I can't see any jumping...

Are you maybe using a Mac and Chrome 51 or 52?

Best regards,
Klaus

herrpedro

Trainee

  • "herrpedro" started this thread

Posts: 134

Location: Lisbon

Occupation: Programmer/analyst

  • Send private message

3

Tuesday, August 30th 2016, 10:11am

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.

herrpedro

Trainee

  • "herrpedro" started this thread

Posts: 134

Location: Lisbon

Occupation: Programmer/analyst

  • Send private message

4

Wednesday, August 31st 2016, 10:20pm

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.
herrpedro has attached the following images:
  • Capture2.JPG
  • Capture.JPG

5

Thursday, September 1st 2016, 11:46am

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:

Source code

1
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:

Source code

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

and got this output when panning around:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
h=0 panoview.h=0
h=-1.1957271583324915 panoview.h=-1.1957271583324915
h=-2.590736550821781 panoview.h=-2.590736550821781
h=-4.185028177467868 panoview.h=-4.185028177467868
h=-5.580037569957158 panoview.h=-5.580037569957158
h=-6.377193027193901 panoview.h=-6.377193027193901
h=-8.170780148301562 panoview.h=-8.170780148301562
h=-9.964349187453864 panoview.h=-9.964349187453864
h=490 panoview.h=-10.761495000776907
h=490 panoview.h=-13.352205031601672
h=490 panoview.h=-14.946491836597177
h=490 panoview.h=-17.33788105979782
h=490 panoview.h=-18.932167864793325
h=490 panoview.h=-21.124285702222906
h=490 panoview.h=-23.316403539652487
h=490 panoview.h=-25.90705691702318
h=490 panoview.h=-28.497710294393872
h=490 panoview.h=-30.889092285993506
h=490 panoview.h=-34.07752125346537
h=490 panoview.h=-39.05940114163485
h=490 panoview.h=-42.64631141958431
h=136 panoview.h=-46.63159457859571
h=136 panoview.h=-50.417750934008794
h=136 panoview.h=-53.60617990148066
h=136 panoview.h=-57.19310102387976
h=136 panoview.h=-59.98301011921602
h=136 panoview.h=-61.77657915836832
h=136 panoview.h=-62.374446354056886
h=136 panoview.h=-62.773025288197275
h=136 panoview.h=-62.374446354056886
h=136 panoview.h=-62.17515688698669
h=136 panoview.h=-61.17871557920208
h=136 panoview.h=-59.98298842086959
h=136 panoview.h=-57.790870583440004
h=136 panoview.h=-55.20021720606931
h=136 panoview.h=-52.60956382869862
h=136 panoview.h=-49.81964629715788
h=136 panoview.h=-47.029737201821625
h=136 panoview.h=-44.23981967028089
h=136 panoview.h=-41.05139070280902
h=878 panoview.h=-35.07331536817255
h=878 panoview.h=-31.287181905213227
h=878 panoview.h=-29.49372134401367
h=869 panoview.h=-24.113350504864666
h=869 panoview.h=-20.924931177894738
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:
https://swizec.com/blog/js-object-optimi…-52/swizec/6908
https://www.reddit.com/r/javascript/comm…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: krpano119pr7test.zip

Best regards,
Klaus

herrpedro

Trainee

  • "herrpedro" started this thread

Posts: 134

Location: Lisbon

Occupation: Programmer/analyst

  • Send private message

6

Thursday, September 1st 2016, 10:50pm

i always think "why me!!!!" lol

yep, working now on updated chrome!

Thanks Klaus!

7

Thursday, September 1st 2016, 11:07pm

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!

This post has been edited 2 times, last edit by "indexofrefraction" (Sep 2nd 2016, 8:35am)