The steps I meant in front of 5.13 are things that apply to all (or most) entry points.Â That is, something like:
Before performing the implementation of any method of the WebGLRenderingContext
interface, the following steps must be performed:
1. If webgl context lost flag
is set, and the called method is not in the list of methods with explicit context lost handling
, perform the following steps and terminate this algorithm.
1.1. If the return type of the called method is any
or any nullable type, return null.
1.2. Terminate this algorithm without calling the method implementation.
2. Otherwise, perform the implementation of the called method and return its result.
The following methods have explicit context lost handling
- isContextLost, checkFramebufferStatus, getAttribLocation, getVertexAttribOffset, isBuffer, isEnabled, isFramebuffer, isProgram, isRenderbuffer, isShader, isTexture
This is a bit awkward, since I'm not aware of anything like this in other specs to draw from, but it's a start.Â I'm ignoring the concurrent thread about null return values (if that does lead to API changes, this is probably where they'd go).Â The synchronous context loss issue would also affect this; this is where checking for a newly lost context would go.
The isBuffer, etc. functions are in the list because their return value depends on the lost object flag
of their argument; they don't care whether the context itself is currently lost or not, and should return false even if webgl context lost flag
is set, not null.
Something this also needs to allow is handling extensions: extension methods (which aren't methods of WebGLRenderingContext) also need to perform these steps.Â If getExtension had a base interface instead of just returning "object" then it could just say "any method of the WebGLRenderingContext
or any WebGLExtension
interface...".Â I suppose "any method of the WebGLRenderingContext
interface or any method of an interface returned by getExtension
" might work.
Or perhaps we can rewrite section 2 to mainly comprise your steps, and delete most of Section 5.14. Do you have a preference?
I think the first paragraph of 2.1 can be removed: that's all either defined here, or by the upstream Canvas API itself.Â (Canvas already defines the "Subsequent calls to getContext ..." behavior, for example, so it doesn't need to be duplicated here.)
I wouldn't try to rewrite the drawing buffer creation parts of section 2 right now, since it'd be biting off too much at once.Â I'd add eg. "To create a drawing buffer
, the following must be performed" somewhere at the top of section 2.Â That ties it to step 4 above ("4. Create a drawing buffer
using the settings..."; note the change in italics), defining what that step in the algorithm means.