[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 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?  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;
        useDefaultReturnValue = true;

    foreach(arg in args) {
        if(arg instanceof WebGLObject && arg.invalidated)
            useDefaultReturnValue = true;

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