Black Face on HTML5 on Chrome (mac) and Chrome (Android 4.2)

  • Sacha, do you mean that we should create a new, separate thread where bug report regarding this should be posted, along with all the details? If so, I can do that, just confirm. Thanks.

    Today, the situation is still the same. Looking at all links to various panos and virtual tours posted in this forums today. Everyones panos have huge holes in them, an all Android based devices. In Chrome. by far the most popular browser. This is DEFCON 1.

  • Thanks for the link, Sacha.

    So that is the correct place where this should be reported ASAP.

    And Klaus should be the one reporting it, since he knows the inner workings of Krpano best and can formulate it most helpfully to Chrome developers.

    Ok, so go ahead, please.

    Waiting on you, Klaus.

    Thanks.

  • Hi,

    first - there is no general problem with Chrome 45 or Android, but it seems that Chrome 45 is blocking the GPU drivers of some devices - and without GPU support there is no WebGL support - and without WebGL support, krpano needs to use CSS3D for displaying the panos.

    That means when WebGL is available, everything is fine. In this case krpano itself almost fully controls the rendering output.


    With CSS3D the browser itself is responsible for the correct 3d rendering. And CSS3D is broken in Chrome since several years (there are already a lot of threads and bugreports about that). The last and only Chrome version where CSS3D was really working correctly was Chrome 18 (and this version is from 2012!).

    Workarounds are not possible here, this is fundamentally broken in Chrome.


    The problem with CSS3D was reported to Google/Chrome a several times.

    Here one bug-report from me:
    https://code.google.com/p/chromium/issues/detail?id=344488


    But I have say I think that providing WebGL support in any case should have more priority to Google than fixing the CSS3D rendering. With WebGL much more is possible (faster rendering, less memory usage, VR, panoramic video, little planet, better blending, lens-flares, 3d-objects and so on). Currently they are blocking WebGL to quickly.

    Best regards,
    Klaus

  • Thanks, Benji.

    Thanks, Klaus.

    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?

    What does "blocking the GPU of some devices" mean? Which devices? What are the stats? Are we talking 1% or 99% of all Android devices? How bad is this?

    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.

    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?

    What do I say to the cients regarding the future of this? Minus the tech talk (= hieroglyphs to them). What do you see forward?

    Thanks!

  • 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

Participate now!

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