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

Re: [Public WebGL] Some WebGL draft feedback

On Wed, Dec 16, 2009 at 7:05 PM, Gregg Tavares <gman@google.com> wrote:
> From: Philip Taylor <excors@gmail.com>
> 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.

I agree. It's not at all clear from the HTML5 spec if you are supposed
to be allowed to get multiple different contexts to the same canvas
(or else I missed that part of the spec that makes that clear)

This seems like a valid thing to want to do.

var c3d = canvas.getContext("webgl");
var c2d = canvas.getContext("2d");
var csvg = canvas.getContext("svg");


I know that so far WebGL has assumed only 1 context is allowed but
maybe we should get a definitive answer.

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

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: