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

Re: [Public WebGL] Help with the WebGL Context Lost specification





On Tue, Dec 6, 2011 at 5:07 PM, Glenn Maynard <glenn@zewt.org> wrote:
, On Tue, Dec 6, 2011 at 6:06 PM, Kenneth Russell <kbr@google.com> wrote:
Sorry for the long delay getting back to this.

The changes discussed above have been applied to this copy of the spec:
 
Cool.  Some comments:

Section 5.14: The text "explicit context lost handling" above the actual list should be emphasized.

Section 5.15.2 "While the context's webgl context lost flag is true" section should be removed, and folded into each function's definition.  For example, add the text "If the context's webgl context lost flag is set, return -1" to getAttribLocation in section 5.14.10.  This keeps the definitions for each function in one place, so the definition of each function isn't scattered in different places and it's easier to read in isolation.  The "All methods returning void" and "All methods returning nullable values or any" parts are already defined by 5.14.

The explicit context lost handling list should include getError.

I'd change 5.5 of 5.15.2 to "Queue a task to restore the drawing buffer", and then remove "queue a task to" from 5.15.3.  (That is, queue the task from the caller of the algorithm, instead of as part of the algorithm.)

5.14 doesn't say what the function (eg. getTexParameter) returns if passed an invalidated texture.  It just says to generate an error and return.  I think this should return the same thing it would if the context itself was lost (eg. steps 1.1 and 1.2).  I'm having trouble thinking of a nice way to spec that without copying-and-pasting those steps; I'll think about this and get back if I come up with something.

The algorithmic sections can probably match the HTML5 spec formatting, at least for now in a couple ways that don't conflict with the rest of the spec's formatting:
- The bolded terms like canvas and context creation parameters, instead of being bold, should be links to the definitions of those terms.
- Algorithm names like "Fire a context creation error" and "Create a drawing buffer" should be bold instead of italic.

How do these look at least as a start? What should be done next?

Some other things (not all urgent):

- EXT_lose_context needs to state that its two methods have explicit context lost handling, or else restoreContext will never work.

Can you be more specific?

EXT_lose_context should effectively do this

1) calling loseContext loses the context. The context will be lost immediately and the steps defined in 5.15.2 are followed except for "queue a task to restore the drawing buffer"
2) calling "restoreContext" "queues a task to restore the drawing buffer" which follows the steps in 5.15.2

 
- WebIDL now has a "dictionary" type, for specifying dictionaries of options to functions.  We should use it here; it handles some finer details.  (For example, if passed an object with getters, are they used?  If so, what order are they called in?)  Using the same mechanism will make sure we answer these details in the same way as other APIs.  I'm not sure exactly what this will look like; DOM event constructors (http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#constructing-events) is probably a good starting point.
- Note that there's an important corollary to the explicit context lost handling list: *every* method which is non-nullable/non-void must be in the list.  Otherwise, we're saying to return null when we can't.  Let's get back to this, since this ties into the other discussion we had about this, and this isn't a regression (the spec is missing nullable declarations anyway).
- Defining "Invalidate all WebGLObject instances" more precisely.
- The context creation algorithm called by getContext can't return null.  We talked about how to fix this before, but it's been a while and we'd probably need to review that discussion to make another pass at it.  I think it basically means always returning a context and queuing an error on the resulting object.  If fixing this is put off too long, it'll become unfixable (eg. the fix might end up breaking too many pages).

--
Glenn Maynard