Recovering from lost context (webglcontextlost)

[alvinhochun]

It seems that the context being lost is only limited to WebGL and not a thing on desktop.

This page goes through what's needed to recover from a context lost, which is a lot of platform-specific code. I wonder if it makes sense at all for Glow to include something to aid this, or perhaps provide some documentations to aid writing compatible code?

These stands out to me:

• The code should not treat gl.getError() == gl.CONTEXT_LOST_WEBGL as a hard error. (Is it normal for code to check glGetError after every GL calls?)
• get_shader_compile_status and get_program_link_status returning false during a context lost should not be considered a hard error.
• gl.createProgram and etc. can return null when context is lost, which means the user should not use .unwrap() or .expect() on the return value of create_program and etc.

Of course the user will still need to handle the webglcontextlost and webglcontextrestored events themself and Glow can't help with that.

[grovesNL]

Yeah it would be nice to figure out how to handle this nicely.

As you mentioned, createProgram and other functions returning null are a bit tricky. We could internally use Option for types like Program so that we propagate Some(WebGlProgram) or None internally. This would avoid the need for users to ever unwrap them. I don't think the glow API is too far away from this already, but we may have to adjust which types the API uses for some function arguments or associated types (probably adding or removing Options in some places).

Is it normal for code to check glGetError after every GL calls?

I don't think so, although some applications inject this after most GL calls for debugging, and some WebGL middleware (WebGL Inspector, Spector.js) will patch GL calls with it.

Of course the user will still need to handle the webglcontextlost and webglcontextrestored events themself and Glow can't help with that.

We might be able to wrap webglcontextlost and webglcontextrestored into some helper functions that no-op on native.

[alvinhochun]

Yeah it would be nice to figure out how to handle this nicely.

As you mentioned, createProgram and other functions returning null are a bit tricky. We could internally use Option for types like Program so that we propagate Some(WebGlProgram) or None internally. This would avoid the need for users to ever unwrap them. I don't think the glow API is too far away from this already, but we may have to adjust which types the API uses for some function arguments or associated types (probably adding or removing Options in some places).

Sounds like a good idea, but what if context lost also needs to be handled on other platforms? (I did think it seems limited to WebGL but I don't actually know if it's true.)

We might be able to wrap webglcontextlost and webglcontextrestored into some helper functions that no-op on native.

The listeners have to be attached to the canvas element and you don't have that on native, so if you do make such helper functions they are going to be conditionally compiled anyway.