[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Comments on Dec 20th draft
On Tue, Dec 20, 2011 at 10:40 PM, Mark Callow <firstname.lastname@example.org> wrote:
> The following statement appears in the non-normative box in the Introduction
> yet it sounds like a normative statement (emphasis mine):
> Many functions described in this document contain links to OpenGL ES man
> pages. While every effort is made to make these pages match the OpenGL ES
> 2.0 specification [GLES20], they may contain errors. In the case of a
> contradiction, the OpenGL ES 2.0 specification is the final authority.
Agreed. I think that we should remove the non-normative style from the
introduction. Doing so wouldn't seem to weaken the spec or impose
undesirable constraints. Consider that the introduction to the 2D
Canvas spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
talks about what it provides, when it's appropriate and inappropriate
to use it, etc.
Chris, what would you think about making that change?
Another alternative would be to make the last two paragraphs of the
introduction normative, but that would be odd -- the first
non-normative text in the spec would be that discussing OpenGL ES 2.0
> Section 2, second sentence, "which must also be created" → "which must be
> created" The "also" makes it seem that creating the drawing buffer is the
> responsibility of the "author" along with creating the context.
On Wed, Dec 21, 2011 at 8:18 AM, Glenn Maynard <email@example.com> wrote:
> On Wed, Dec 21, 2011 at 2:06 AM, Gregg Tavares (wrk) <firstname.lastname@example.org>
>> On Tue, Dec 20, 2011 at 10:40 PM, Mark Callow <email@example.com>
>>> 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
>>> 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.
Thanks -- fixed by removing this sentence, which was probably left
over from the refactoring of this section.
>>> 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
Yes, the intent here is to give flexibility to implementations if they
can find a more efficient way to initialize these memory regions.
> 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".
This change sounds good; it's been applied.
>>> 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.
Yes, that's a typo. Fixed.
> I think "fire a WebGL context creation error" can also be removed, folding
> the step into the place it's used, like other events.
It's convenient to have this event split into its own section (as with
the context lost and restored events) so that there's a good place to
host the example of handling the event. For the time being I've left
>> 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
> 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
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: