Hi,
Klaus, does all of that change the fact that Krpano is not able to display panos correctly on the most popular browser, Chrome, on the most popular mobile platform, Android, right now?
But that's not the case - it's not Android at all, only some devices aren't supported by Google Chrome yet.
What does "blocking the GPU of some devices" mean? Which devices?
The GPU drivers of Android devices which don't support one of two specific features are blocked by Google at the moment. According to the discussions and change-logs at the Chrome source (see the links
here) this was done for 'stability' to avoid that 'bad' WebGL code in one tab could affect the whole browser.
What are the stats? Are we talking 1% or 99% of all Android devices? How bad is this?
Sorry, but from where should I know this?
Additionally I'm neither responsible for that changes in Chrome nor I can change them.
This is the picture I am currently seeing: Everyone I ask that is using Chrome on Android is seeing the same huge holes in all Krpano supported panos as can be observed in the images above in this thread. Incl. all panos on this website and in this forum.
That's your point of view, but that's not necessarily true for 'everyone'.
E.g. all my current Android test devices (Nexus7, Nexus9, SG5, Note4, LG G3) are still having WebGL support with Chrome 45.
Also, just curious, do you think Chrome should adjust to Krpano or should Krpano adjust to Chrome? Or who should do what here to fix this ASAP?
These things are possible:
- Google relaxes their GPU blacklist policy or develops better workaround for GPU bugs .
- The developers of the affected GPU drivers are fixing the drivers and the manufacturer of the device provides a system update.
- Google fixes their CSS3D rendering bugs.
But it's
technically not possible to fix these problems from HTML5/Javascript (=krpano) side!
What you could do is to add some xml code to check for Android Chrome 45 and missing WebGL support and show the user something like 'sorry your device/browser isn't supported, please try another browser'.
How come this viewer, just one example, works without WebGL on same tablet where Krpano shows huge holes in panos?
https://pannellum.org
It's the combination of several things that are triggering the CSS3D bugs - e.g. how the css3d elements are internally layered - with some combinations you can get sometimes correct rendering but often with other disadvantages - e.g. like missing touch support for hotspots (like the pannellum example when using CSS3D), or when other layers above were added it can still break again. I've spend already an incredible amount of time trying to find fully working workarounds for the Chrome CSS3D bugs, but without success so far. But if you think that viewer works better, please just use it.
Generally I would say complaining here wouldn't help, I can't help or change the Chrome internals and hacking around the bugs isn't possible, especially no hack can bring WebGL support back when blocked.
That means please report or discuss that problems directly at Google Chrome (links
here) or try to get answers directly from the Chrome developers. E.g. the responsible Chrome developer for WebGL and the GPU blacklisting the is Brandon Jones, he is also on
Twitter.
Here my tweet to him and his answers:
https://twitter.com/klausreinfeld/status/641842335077244928
Best regards,
Klaus