Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recovering from lost context (webglcontextlost) #119

Open
alvinhochun opened this issue Aug 20, 2020 · 2 comments
Open

Recovering from lost context (webglcontextlost) #119

alvinhochun opened this issue Aug 20, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@alvinhochun
Copy link
Contributor

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
Copy link
Owner

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.

@grovesNL grovesNL added the enhancement New feature or request label Aug 21, 2020
@alvinhochun
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants