[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) <firstname.lastname@example.org>
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
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.