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

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



On Fri, Dec 23, 2011 at 3:40 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Tue, Dec 20, 2011 at 10:17 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> I am very reluctant to completely redefine the semantics of the "is"
>> methods. They are supposed to be defined in terms of the analogous
>> OpenGL calls like glIsTexture, glIsShader, etc. Hypothetically, if
>> OpenGL's deletion semantics were changed in some way, then WebGL's
>> "is" methods should pick up the change in behavior.
>>
>>
>> I've revised these methods' definitions to refer to the invalidated flag.
>
>
> OpenGL isn't fully defining context loss (which is why we have this flag to
> begin with), so I think this is the correct thing to do.
>
>
>> > 1. If the called method is in the list of methods with explicit error
>> > handling, perform the implementation of the called method, return its
>> > result
>> > and terminate these steps.
>> > 2. Let use default return value be false.
>> > 3. If the webgl context lost flag is set, let use default return value
>> > be
>> > true.
>> > 4. If any argument to the method is a WebGLObject with its invalidated
>> > flag
>> > set, generate an INVALID_OPERATION error and let use default return
>> > value be
>> > true.
>> > 5. If use default return value is true, perform the following steps:
>> >
>> >     5.1. If the return type of the called method is any or any nullable
>> > type, return null.
>> >     5.2. Terminate this algorithm without calling the method
>> > implementation.
>> > 6. Otherwise, perform the implementation of the called method and return
>> > its
>> > result.
>> >
>> > (This could probably be more concise, but it seems clear.)
>>
>> These suggested changes are pretty verbose and I'm not convinced
>> they're needed. Step 2.2 delegates either to the behavior in step 1.1
>> or the behavior defined by the method's explicit context lost
>> handling. I think the added verbosity will confuse the issue more than
>> clarify it.
>
>
> You meant 2.2 to call the method implementation for
> explicit-context-lost-handling functions?

(Sorry for the delay getting back to this.)

It was intended to refer back to the set of steps again, essentially
in recursive fashion.

However, upon re-reading your steps, I agree that they're the most
straightforward way to express the intent. I've updated the spec in
that area, and added a necessary check to the spec for
getAttribLocation in the case where the passed WebGLProgram's
invalidated flag is set. Thanks for this update.

I hope that we're either finished, or close to being finished, with
the context lost related changes for this revision of the WebGL spec.
Are any other changes needed?

-Ken

>  I didn't realize that at all (it
> explicitly says "terminate without calling the implementation"), so I think
> it's currently unclear.  The above is verbose, but I think very clear.  It
> translates directly to pseudocode:
>
> invokeMethod(f, args)
> {
>     if(f in explicitErrorHandlingFunctions)
>         return f(args);
>
>     useDefaultReturnValue = false;
>     if(webglContextLost)
>         useDefaultReturnValue = true;
>
>     foreach(arg in args) {
>         if(arg instanceof WebGLObject && arg.invalidated)
>         {
>             useDefaultReturnValue = true;
>             error(INVALID_OPERATION);
>             break;
>         }
>     }
>
>     if(useDefaultReturnValue)
>     {
>         if(returnType(f) == "any" || isNullable(returnType(f)))
>             return null;
>
>         // All methods with non-nullable, non-void return types must have
>         // explicit error handling, or we don't know what to return.
>         assert(returnType(f) == "void");
>         return;
>     }
>
>     return f(args);
> }
>
>>
>> > "Queue a task" ->
>> > http://dev.w3.org/html5/spec/webappapis.html#queue-a-task
>>
>> Fixed. Do we need a new reference? Is this definition contained in any
>> of the existing references?
>
>
> It's part of HTML5, so it's already referenced.
>
>
>> The task source for queued events needs to be defined: "The task source
>> for
>> these tasks is the WebGL task source."  I'm not sure where that should go;
>> it affects the API globally.
>
>> If you could suggest where to place this I'd appreciate it.
>
>
> It could go in its own small section, as XHR2 does
> (http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#task-sources), perhaps
> as section 1.2.  It's not really introductory--it's just a definition
> affecting the rest of the spec--but that's probably good enough.
>
> --
> Glenn Maynard
>

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