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

[Public WebGL] Some WebGL draft feedback



Some comments about the current draft (up to section 5.2):

About getContext(): I don't understand what should happen in the
following cases:

  var a = canvas.getContext('webgl');
  var b = canvas.getContext('2d');
  var c = canvas.getContext('webgl');
  // Is a == c now?
  // Are the WebGL contents still shown on the page?

  var a = canvas.getContext('2d');
  var b = canvas.getContext('webgl');
  a.fillRect(0, 0, 100, 100);
  // Does this rectangle get drawn or displayed anywhere?

Detaching the WebGL context when getContext(different-string) is
called will prevent a useful extension point - e.g. Opera has
getContext('opera-2dgame') which returns a context with a few extra
functions that interact with the normal 2D context, and a similar
model could be useful to provide extensions to the WebGL context.

The getContext definition seems to differ significantly from the
canvas model described by HTML5 - in the HTML5 view of things, the
canvas has a single bitmap (which gets rendered to the display, and
returned by toDataURL) plus any number of contexts that might read and
modify that bitmap. Is WebGL fundamentally incompatible with that
model (because of performance or implementation complexity or
something)? WebGL should work with the HTML WG to make sure they end
up specifying compatible things (and to make sure the model should
work with future new canvas contexts).
(http://www.w3.org/Bugs/Public/show_bug.cgi?id=8476 is a relevant
place on the HTML WG side.)

I don't know a good solution for these issues, but I think there is a
problem that needs to be discussed and solved.

"A second parameter may be passed to the getContext() function." - if
you're changing the semantics of HTML5-defined interfaces, they should
be defined clearly (e.g. using IDL) and made clear that they differ
from HTML5. But ideally HTML5 itself would be changed, so WebGL
doesn't have to override it, so I'd suggest discussing with the HTML
WG.

"If passed, this parameter shall be a WebGLContextAttributes object" -
what happens if it's not?

Consider the following situation:
* The user configures their browser to disable WebGL (to block
obnoxious 3D ads or whatever).
* The user visits a page with a cool 3D game.
* The page calls getContext('webgl', attrs).
* The browser returns null because WebGL isn't currently supported.
* The page tells the user "please turn back on WebGL", so the user
does so, then clicks the "try again" button.
* The page calls getContext('webgl') to check.
Because things are defined in terms of "calls to getContext() with the
'webgl' string", the spec seems to require that the first 'attrs' is
used, but that seems weird from an implementation perspective - really
you just want to use the attributes at the point when the WebGL
context is created. Is this intentional? Probably it should be
specified in terms of when the context is created, rather than when
getContext is called.

"The size of this drawing buffer shall be determined by the width and
height attributes of the HTMLCanvasElement." - how are they determined
from the attributes? Are they meant to be equal in pixels to the
attribute values? In some 2D context implementations (e.g. WebKit),
the size of the buffer is the attribute values multiplied by a UI
scaling factor (typically 1.0 but it might be configured higher on
high-res screens) - should/could they do the same with WebGL?

"the contents of the drawing buffer shall be undefined" - that sounds
unacceptable for interoperability - somebody will write code that
depends on the buffer being unchanged, or being cleared to (0,0,0,0),
and test it in one major implementation, and then every other
implementation will be forced to follow suit, so it should just be
specified now.

"an implementation may choose to raise an exception, use the closest
valid index, use 0, ..." - that sounds unacceptable for
interoperability for the same reasons. (With the 2D context, there
have been several cases (e.g. negatively-sized arcs) where one
implementation throws an exception while another ignores the call, and
people write code relying on the ignore behaviour, and their pages
break in implementations that throw exceptions, so it's a pain for
everyone involved. There's a much better chance of interoperability if
the spec specifies the behaviour.)

"For drawArrays, each bound VBO must be at least as large as needed" -
what if it isn't?

Security: Can I write a shader which takes very little time for
certain fragment values, but a measurable time for other values? If
so, I could circumvent the origin restrictions by reading from
different-origin textures one bit at a time, which breaks the security
model.

Origin restrictions should list texSubImage2D as well as texImage2D.

What happens if I create a WebGLTexture in one canvas (perhaps causing
that canvas to become origin-unclean), and then try to bind and use it
in a different canvas (and perhaps read it back with readPixels)?

WebGLContextAttributes: "the string is converted to a number" - how is
it converted? (What is "+10", "0xa", "1e2", etc?)

For numbers and booleans I'd expect to have the same behaviour as
normal WebIDL/ECMAScript conversions
(http://dev.w3.org/2006/webapi/WebIDL/#es-boolean etc, where "" is
false, but "0" is true, and "false" is true). The IDL would probably
have to specify 'any' rather than 'DOMString' in that case.

========

As already mentioned (by Robin Berjon), the use of normative language
needs to be clarified. I'll presume "must", "shall", "may" etc are
always meant to be interpreted with their RFC 2119 definitions.

It would be nice to be consistent with HTML5, which never uses "shall".

The normative language is not used entirely precisely. (My perspective
is as someone who wrote
http://philip.html5.org/tests/canvas/suite/tests/ and has therefore
tried to read the HTML5 canvas spec very pedantically; it has had
similar issues to the WebGL spec but they have been fixed, so I'm
hoping WebGL can become as precise). In general, I expect something
like:

* Whenever "must"/"shall"/"should" is used, it ought to be clear
whether the requirement is on the author (who is using the API) or the
implementation. If it's an author requirement, it should be possible
to write pages that violate the requirement (otherwise the requirement
is pretty useless). If it's an implementation requirement, it should
be possible to write a test case to check if it's violated or not.

* Those words should not be used in any other context or with any other meaning.

* Any testable requirement should be specified normatively at least
once, and no more than once.

(I'm not suggesting this is the only possible way of using normative
language, but I think it's a way that is possible (HTML5 does it; see
also <http://ln.hixie.ch/?start=1140242962&count=1>) and can lead to
unambiguous and easily-testable text, so I'd like it to be the goal.)

Some particular examples from the current draft:

"the author must obtain a WebGLRenderingContext object" - shouldn't
say "must" (it's not a normative requirement).

"the drawing context, which must also be created at the time of
context creation" - shouldn't say "must" (it doesn't say who/what must
create it, and it doesn't say what context creation is, so it's not a
good requirement; better to just specify the requirement later when
defining the semantics of getContext.)

"This drawing buffer is presented to the HTML page compositor ..." -
this sounds like it's trying to say something specific, but what is an
HTML page compositor? Is it meant to be a normative requirement? How
could I write a test case that tells if the implementation is doing
something different?

"A WebGLRenderingContext object shall be created" - is that a
requirement on authors, or on implementations?

"The resources represented by these objects are guaranteed to exist as
long as the object exists." - is that meant to be a normative
requirement? If so, it should say "must" or "shall". Same for next
sentence.

"For example, this may require creating a temporary buffer of 0
values" - shouldn't say "may" (since it's not used with the RFC 2119
meaning).

"User agents should implement safeguards" - either this shouldn't say
"should", or the section should not be explicitly non-normative.

There's no normative requirements on the handling of
WebGLContextAttributes parameters at all.

========

Minor typos etc:

"The HTMLCanvasElement places an element on the page" - should say
something like "The HTML <canvas> element places an object on the
page" (HTMLCanvasElement is just an IDL interface name, it doesn't
place anything anywhere, and the element would exist even in
implementations that don't support scripting).

"which presents and API" - s/and/an/

"the time of context creation.." - s/.././

"indirectly by via rendering" - s/via//

"a numerica value" - s//l/

-- 
Philip Taylor
excors@gmail.com
-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: