[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.

Done.

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/specs/latest/index-context-lost.html

> 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.

OK. I was very hesitant to make this change originally, but see that
it now affects relatively few methods. Done.

> The explicit context lost handling list should include getError.

Done.

> 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.)

Done.

> 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.

Added some words referring to the value that would be returned if the
context were lost. What do you think?

> 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.

I see. All of these references have been updated in the new draft.
Please point out if any were missed.

>> 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.

I'll do this once this new draft becomes the main draft.

> - 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.

To be clear, are you suggesting to make WebGLContextAttributes a
dictionary? I don't see any other place in the spec where one would be
relevant. Currently it's specified as [Callback], which seems to be
sufficient for our purposes (taking user objects as arguments and also
allowing the type to be returned from methods).

> - 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).

Yes, let's defer this.

> - Defining "Invalidate all WebGLObject instances" more precisely.

Let's fix this next. If you could suggest some wording I'll incorporate it.

> - 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).

I strongly believe we should defer this discussion until after the
next snapshot of the spec. The working group has discussed this
extensively, including at the most recent face-to-face meeting, and no
progress was made. I do not think that returning a no-op context with
a pending error is workable, because current canvas applications (not
just WebGL) expect context creation to be synchronous. The best
solution is probably to make WebGL context creation asynchronous, and
require that the application handle context restored events in order
to even start up. However, this is an incompatible change, and we'll
have to figure out how to introduce it.

-Ken

-----------------------------------------------------------
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
-----------------------------------------------------------