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

Re: [Public WebGL] Comments on Dec 20th draft

On Wed, Dec 21, 2011 at 2:06 AM, Gregg Tavares (wrk) <gman@google.com> wrote:
On Tue, Dec 20, 2011 at 10:40 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
2.1, item 1, ", which is a canvas.", seems unnecessary. If you really want this phrase add "object".

It defines the type of this object.  The bolded word "canvas" is merely a label (eg. a variable name).  In pseudocode, this is "Canvas canvas;".

2.1, item 2, Plurality does not match: "has ... parameters which is." Change ", which is" →"in".

"context creation parameters" is also a label.  If you say "WebGLContextAttributes contextCreationParameters;" in a programming language, the result is singular: one variable.

First sentence of 2.2 "following shall be performed." is followed by ... no steps.

It's referring to the rest of 2.2.  Refactoring the text of 2.2 into a list of steps is a task for another time, if it's considered necessary at all.  (I think that's less important.)  This could be clarified if needed; the important part is that this section defines the operation "create a drawing buffer".

Also in 2.2 2nd 'graph after the table "By default, the buffers shall be the size shown below." Where? The size is not given in 2.2.

In 4.1 "For example, this may require" → "This may require". "For example" has no relevance in this context.

It implies that there may be other ways to implement the requirements, I guess.

I had some trouble parsing "a temporary buffer of 0 values the size of a requested VBO"; it reads "of zero length" to me.  Maybe "this may require creating a zeroed temporary buffer the size of a requested VBO".

In 5.14 "Before performing the implementation of any method" → "Before invoking any method". and "perform the implementation of the called method" to "invoke the called method."

I guess either works, but I pictured these steps as part of the method invocation itself.

In 5.15 type & isTrusted attributes mentioned in the text do not appear in the IDL for WebGLContextEvent.

See the base class, defined in DOM4.
In 5.15.4, why fire a webglcontextrestored event before firing a context creation error? It seems bizarre and no explanation is given.

Copy/paste error, I guess.  s/webglcontextrestored/webglcontextcreationerror/

I think "fire a WebGL context creation error" can also be removed, folding the step into the place it's used, like other events.

That seems more different than real OpenGL. In real opengl there are no errors and all GL functions are no-ops and don't generate any errors. The intent is that losing the context clears all un-gotten errors and generates one more, CONTEXT_LOST_WEBGL. After that just like real GL all functions are no-ops 

Does the ES spec actually allow implementations to return from functions both without any side-effects and without generating an error?  (If so, where?  I couldn't find anything in the spec searching for a few obvious keywords.)  I've always assumed the whole context loss thing is to allow eg. Direct3D implementations, since I've never even seen an OpenGL implementation that can lose the context.

Glenn Maynard