[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] appropriate context loss response

It would be very useful to somehow let the js code know that there is a problem, so that it can show alternate content e.g. simplified WebGL content or content not using WebGL at all. I am using WebGL
in a way to improve the look of classical web pages and in this kind of application it is not a very big problem if the WebGL content does not show but its a big problem if it breaks the page completely.

Am 11/11/2015 um 7:01 PM schrieb Florian Bösch:
As more JS/Canvas/WebGL is being embedded on third party pages around
the mobile web (because no flash), it becomes quite a bit of a problem
if iOS safari throws a hissing fit everytime an iFrame or WebGL context
on a page exceeds its (unknown and unknowable) resource limit and
therefore borks the whole page. But this is the WebGL specification ML,
we can't mandate that browsers behave nicely for everything, we could
mandate they don't throw hissing fits if WebGL is being used in fashion
that exceeds invisible resource limit border.

On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson <dino@apple.com
<mailto:dino@apple.com>> wrote:

    On 11 Nov 2015, at 9:51 AM, Florian Bösch <pyalot@gmail.com
    <mailto:pyalot@gmail.com>> wrote:

    On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson <dino@apple.com
    <mailto:dino@apple.com>> wrote:

        I do think it should (must?) be "acceptable" to kill the
        process/page completely if necessary.

        Obviously detecting that the context is broken and firing a
        context lost event is the preferred option, but I don't think
        we can require all implementations to always recover gracefully.

The issue is that if you kill the whole page, a reload will just kill it again in an endless loop (or however many auto-reloads iOS safari does by itself). It's night impossible to use iOS safari if it does that (closing the tab manually becomes quite challenging etc.). It also leaves the JS on the page with no clue that it did something bad (munch too much vram or whatever) and so no avenue to rectify/address the "bad" behavior. On the whole it's just really, really bad, is why I think it'd make a fairly good requirement for a specification.

Safari should only reload the page twice and then give up. It's definitely a bug if it reloads constantly.


H.E.I. Informationssystems GmbH   |  Wimpfenerstraße 23 | 68259 Mannheim
Germany | Ph:+49 621-795141 | Fax: +49 621-7951 | emmel@taccgl.org
Geschäftsführer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091
            Handelsregister: HRB 7273 | Amtsgericht Mannheim
             http://www.taccgl.org   |   http://www.h-e-i.de

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl