From aru...@ Thu Dec 10 13:56:31 2009 From: aru...@ (Arun Ranganathan) Date: Thu, 10 Dec 2009 13:56:31 -0800 Subject: [Public WebGL] WebGL Draft Specification Released Message-ID: <4B216E8F.8090102@mozilla.com> We're delighted to announce that we've posted a draft version of the WebGL specification[1] to the newly minted khronos.org/webgl [2] website. I've also blogged about the release on hacks.mozilla.org [3]. The release of the draft specification[1], and the creation of this listserv, along with the Wiki [4] and the WebGL Forum [5] gives us a way to interact with the web community, which I think is *crucial* to taking this specification from draft status to final status. WebGL is in nightly builds of most major browsers -- Firefox, Safari, and Chrome -- with Opera as an active participant in the working group. Current implementations (still in beta) give developers a low-level 3D API in JavaScript, and we've already seen the emergence of some really compelling content on the web. We can't wait to hear from developers, and to see what they'll do with WebGL! -- A* [1] Draft Spec: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html [2] WebGL web site: http://webgl.org/ [3] Article on hacks: http://hacks.mozilla.org/2009/12/webgl-draft-released-today/ [4] Wiki: http://khronos.org/webgl/wiki [5] Web Forum: http://www.khronos.org/message_boards/viewforum.php?f=35 -- Arun Ranganathan, Chair of the WebGL WG Mozilla Corporation ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From aru...@ Fri Dec 11 14:27:45 2009 From: aru...@ (Arun Ranganathan) Date: Fri, 11 Dec 2009 14:27:45 -0800 Subject: [Public WebGL] Feedback from HTML5 WG on WebGL | [Fwd: Re: WebGL | The 3D Canvas Context for HTML] Message-ID: <4B22C761.4080400@mozilla.com> Since our release yesterday, we've got some feedback from the W3C HTML5 Listserv. Most of the WHATWG post on the HTML5 listserv at W3C, which has the advantage of attracting Microsoft participation. The W3C HTML5 listserv is archived publicly here: http://lists.w3.org/Archives/Public/public-html/ -------------- next part -------------- An embedded message was scrubbed... From: "Anne van Kesteren" Subject: Re: WebGL | The 3D Canvas Context for HTML Date: Fri, 11 Dec 2009 10:20:47 +0100 Size: 3101 URL: From kbr...@ Fri Dec 11 14:42:48 2009 From: kbr...@ (Kenneth Russell) Date: Fri, 11 Dec 2009 14:42:48 -0800 Subject: [Public WebGL] Feedback from HTML5 WG on WebGL | [Fwd: Re: WebGL | The 3D Canvas Context for HTML] In-Reply-To: <4B22C761.4080400@mozilla.com> References: <4B22C761.4080400@mozilla.com> Message-ID: <921bb10912111442n4e00e920t2d318d84176e7c10@mail.gmail.com> We certainly do want to begin discussions with other working groups to see how the new array-like types might be repurposed. I am sure that some extensions to their APIs will be necessary to fit uses like file I/O. I hope we can achieve a good balance between functionality and simplicity of the API; similar APIs which were developed for Java ended up being both too complicated and difficult to optimize. -Ken On Fri, Dec 11, 2009 at 2:27 PM, Arun Ranganathan wrote: > Since our release yesterday, we've got some feedback from the W3C HTML5 > Listserv. ?Most of the WHATWG post on the HTML5 listserv at W3C, which has > the advantage of attracting Microsoft participation. ?The W3C HTML5 listserv > is archived publicly here: http://lists.w3.org/Archives/Public/public-html/ > > On Thu, 10 Dec 2009 23:47:07 +0100, Arun Ranganathan > wrote: >> >> [...] > > I've been trying to cut my mailing list subscriptions recently so hopefully > someone can forward this as appropriate. > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html > > The draft appears to use outdated Web IDL syntax. It also uses features, > e.g. NameDeleter that are controversial with TC39 so you may want to > reconsider using those. > > It also seems that a bunch of the new objects introduced should really be > part of ECMAScript instead. E.g. all the new typed array interfaces. > > Some of the typedefs are scoped to WebGLRenderingContext but are in fact > used all over the place. > > Also, why is it WebGLRenderingContext and not CanvasRenderingContextWebGL > which would be more consistent with the existing CanvasRenderingContext2D? > > It does not seem to be defined when the event defined at the end of the > specification is actually dispatched. The name of the event is also not > defined, just the interface it implements. Also, if more than one resource > is lost, which one does "resource" return? And why do you need the context > attribute? Isn't it already clear that the event is for the WebGL context? > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > > ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Fri Dec 11 15:49:49 2009 From: cma...@ (Chris Marrin) Date: Fri, 11 Dec 2009 15:49:49 -0800 Subject: [Public WebGL] Feedback from HTML5 WG on WebGL | [Fwd: Re: WebGL | The 3D Canvas Context for HTML] In-Reply-To: <4B22C761.4080400@mozilla.com> References: <4B22C761.4080400@mozilla.com> Message-ID: <0BC0F865-9450-4F81-9904-220A9D94A648@apple.com> On Dec 11, 2009, at 2:27 PM, Arun Ranganathan wrote: > ...From: "Anne van Kesteren" > Date: December 11, 2009 1:20:47 AM PST > To: arun...@, "HTML WG" > Subject: Re: WebGL | The 3D Canvas Context for HTML > > > On Thu, 10 Dec 2009 23:47:07 +0100, Arun Ranganathan > wrote: >> [...] > > I've been trying to cut my mailing list subscriptions recently so > hopefully someone can forward this as appropriate. > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html > > The draft appears to use outdated Web IDL syntax. It also uses > features, e.g. NameDeleter that are controversial with TC39 so you > may want to reconsider using those. I'd like to see more details on how our syntax is out of date and controversial > > It also seems that a bunch of the new objects introduced should > really be part of ECMAScript instead. E.g. all the new typed array > interfaces. I'm not sure what this means. Does the poster believe these should be part of the ECMAScript spec, alongside Array and String? This seems too special purpose for that. Doesn't this same issue exist in the FileIO WG? Is there a reasonable place to put general purpose classes like these? > > Some of the typedefs are scoped to WebGLRenderingContext but are in > fact used all over the place. I am starting to hate the typedefs. Should we just nuke them entirely? > > Also, why is it WebGLRenderingContext and not > CanvasRenderingContextWebGL which would be more consistent with the > existing CanvasRenderingContext2D? This was a conscious decision. It was done to give all the WebGL API's a common prefix. I think that decision is still a good one. > > It does not seem to be defined when the event defined at the end of > the specification is actually dispatched. The name of the event is > also not defined, just the interface it implements. Also, if more > than one resource is lost, which one does "resource" return? And why > do you need the context attribute? Isn't it already clear that the > event is for the WebGL context? Yes, this is a new feature. I will try to shore up the descriptions. ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aru...@ Mon Dec 14 06:52:46 2009 From: aru...@ (Arun Ranganathan) Date: Mon, 14 Dec 2009 06:52:46 -0800 Subject: [Public WebGL] Re: WebGL | 3D Context for Canvas API In-Reply-To: References: <4B217EE9.1000204@mozilla.com> Message-ID: <4B26513E.9070206@mozilla.com> Further review, this time from public-device-apis...@ -- Robin Berjon is the Chair of the DAP WG. We've had comments from public-html...@ as well. This is the advantage of wide review from the open web community :) Robin Berjon wrote: > Hi Arun, > > On Dec 11, 2009, at 00:06 , Arun Ranganathan wrote: > >> Today, the WebGL WG at Khronos [1] released a public draft of the WebGL specification [2], and we really welcome (and need) wide review. >> > > Thanks for keeping us appraised of your progress, please continue to do so as WebGL progresses. It's exciting stuff indeed! > > It would be great if someone (or several people) on this WG were to take an action to review this draft in detail. My 3D days are a bit too far away for me to get far into the technical side. > > Some notes: > > - Could you clarify your usage of RFC 2119 normative terminology? You cite it in reference but it's unclear in the actual prose when a normative term is intended or when the editor might have used one such term as just regular English. Notably "shall" seems to be used a fair bit, which is a 2119 term but rarely used so that clarifying its use would be helpful. Furthermore it would be good if testable assertions were written as such (see http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html), for instance "But the contents shall no longer be shown on the page" -> "When WebGLRenderingContext is detached from its Canvas object, the user agent MUST/SHALL stop displaying it" (or something like that). > > - Providing definitions of terms and cross-linking them throughout the document would be helpful. > > - 2.1 "Subsequent calls to getContext() with the same string shall return the same object" and "On subsequent calls to getContext() with the ?webgl? string, the passed WebGLContextAttributes object, if any, shall be ignored." Presumably that's subsequent calls on the same element object? > > - 2.2 "Changing either of [the width or height] attributes shall cause the drawing buffer to resize and its contents to be cleared to (0,0,0,0)." If I call setAttribute or use .width to set these to the same value that they already have (i.e. change them, but without changing the actual value) does the clearing take place? > > - 3 "textures, buffers (i.e., VBOs) framebuffers," There's a missing comma. > > - 3 "Furthermore, the DOM object is guaranteed to exist as long as the author has an explicit valid reference to it OR as long as it is bound by the underlying graphics library." There probably isn't a need to capitalise the "OR". What does it mean for a DOM object to be bound by an underlying graphics library? This sounds implementation specific though it appears to want to be normative. > > - 4.1 "If a caller attempts to access any data outside of that range, an implementation may choose to raise an exception, use the closest valid index, use 0, or any other approach that prevents it from providing access to uninitialized data." Is it possible that you would agree on a single error handling behaviour for this case? > > - 4.2 "the WebGL implementation must ensure that the shader cannot access either out of bounds or uninitialized data" Same thing, can it be defined what happens in such a case? > > - 5.1 "The keys identify the feature being set to the given value, which is typically a boolean ("true" or "false") or numeric value." The IDL and subsequent prose makes the values be DOMStrings. Automatic conversion will make it work anyway, but couldn't the API just accept "any" instead? > > - You don't ever use NoInterfaceObject, is the intent that all interfaces be exposed in the global scope? > > - 5.3 "The underlying object is created as if by calling glGenBuffers , bound as if by calling glBindBuffer and destroyed as if by calling glDeleteBuffers." (Similar discussion occurs in other interfaces). I understand that the idea is to expose a wrapper around OpenGL ES objects, and I assume that that's what's meant by "underlying object". A clear discussion of this (and an indication of whether it is acceptable to implement WebGL on something other than OpenGL so long as the output is the same ? which I presume is the case) would be helpful. Also, since what a large bunch of these interfaces mean appears to depend on another document, it would be good to link to those definitions in that document, or if that proves impossible (e.g. because it's a PDF...) to inline a definition. > > - 5.9 WebGLObjectArray. Is the intent that it would be exposed as a JS Array? Same for other interfaces that look like arrays. > > - 5.11 "type of type GLenum. The data type of the requested variable." Where do I get that enum's values? > > - OMG, IDL templates! > > - 5.14 The interface contains typedefs that seem to be used elsewhere. It's unclear to me from WebIDL whether typedef declarations are scoped (in which case you'd have to move them out of the interface, and *gasp* perhaps use a module), or if the typedef namespace is just global. > > - Man, WebGLRenderingContext really is the mother of all interfaces! I think there's an award in there ? comes out to 23 screenfuls here. This is just a thought but maybe it would be more readable if it were (editorially) somehow split into several sections that combined would be the full thing (as is done with the prose)? At the very least linking from the interface to the prose (and back, if possible) would make things easier, perhaps even just linking between IDL sections and prose sections. Perhaps the IDL could even include some direct links to the OpenGL man page? > > - 5.15 "These events are sent to the corresponding HTMLCanvasElement through the DOM Event System." It would be better to call it "DOM Level 2: Events" and to have a reference instead of a direct link (or to have both). > > - Also, "The resource attribute contains the resource that was lost, or null if all resources were lost." could be clarified a little bit. Right now it reads a bit like "Well I lost it so I'm giving it to you, unless I completely lost it" :) > > Anyway, great work, I look forward to more! > > -- > Robin Berjon > robineko ? hired gun, higher standards > http://robineko.com/ > > > > > ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From exc...@ Mon Dec 14 11:07:40 2009 From: exc...@ (Philip Taylor) Date: Mon, 14 Dec 2009 19:07:40 +0000 Subject: [Public WebGL] Some WebGL draft feedback Message-ID: 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 ) 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 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...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Tue Dec 15 18:51:47 2009 From: kbr...@ (Kenneth Russell) Date: Tue, 15 Dec 2009 18:51:47 -0800 Subject: [Public WebGL] Minor spec edits Message-ID: <921bb10912151851j6bf7837du28bc89d08a32d97d@mail.gmail.com> I've checked in a few minor spec edits: 1. Added needed commas after a couple of the WebGL[T]Array Constructor extended attribute declarations. 2. Added missing GLboolean type for asPremultipliedAlpha argument. 3. Added missing "in" qualifier for flipY argument. Thanks to Shiki Okasaka for pointing out (1) and (2). -Ken ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Wed Dec 16 07:39:32 2009 From: cma...@ (Chris Marrin) Date: Wed, 16 Dec 2009 07:39:32 -0800 Subject: [Public WebGL] Minor spec edits In-Reply-To: <921bb10912151851j6bf7837du28bc89d08a32d97d@mail.gmail.com> References: <921bb10912151851j6bf7837du28bc89d08a32d97d@mail.gmail.com> Message-ID: On Dec 15, 2009, at 6:51 PM, Kenneth Russell wrote: > I've checked in a few minor spec edits: > > 1. Added needed commas after a couple of the WebGL[T]Array Constructor > extended attribute declarations. > > 2. Added missing GLboolean type for asPremultipliedAlpha argument. > > 3. Added missing "in" qualifier for flipY argument. > > Thanks to Shiki Okasaka for pointing out (1) and (2). Thanks, Ken ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Wed Dec 16 19:18:56 2009 From: gma...@ (Gregg Tavares) Date: Wed, 16 Dec 2009 19:18:56 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: References: Message-ID: On Wed, Dec 16, 2009 at 7:05 PM, Gregg Tavares wrote: > From: Philip Taylor > 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"); Draw3DWorldWith3dContext(c3d); DrawTextLabelsOfThingsIn3DWith2dContext(c2d); DrawUIWithSVG(csvg) 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 ) 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 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...@ > ----------------------------------------------------------- > You are currently subscribe to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Fri Dec 18 10:49:40 2009 From: cma...@ (Chris Marrin) Date: Fri, 18 Dec 2009 10:49:40 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: References: Message-ID: <99846A33-644F-48FD-B229-888685B3D6BB@apple.com> On Dec 16, 2009, at 7:18 PM, Gregg Tavares wrote: > On Wed, Dec 16, 2009 at 7:05 PM, Gregg Tavares wrote: >> From: Philip Taylor >> 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"); > > Draw3DWorldWith3dContext(c3d); > DrawTextLabelsOfThingsIn3DWith2dContext(c2d); > DrawUIWithSVG(csvg) > > I know that so far WebGL has assumed only 1 context is allowed but > maybe we should get a definitive answer. This is one of the issues we wanted to discuss with the HTML5 WG, a conversation that was predicated on the spec going public. Now that it has, we should get moving on that conversation. As for your proposal above, I disagree that you should be able to have multiple active contexts for a given canvas. A Canvas element represents a single rectangular rendering area, so it seems reasonable to restrict it to a single mode of rendering at a time. Otherwise there are both implementation and specification issues having to do with synchronization and resource issues that it would be best to not have to solve. If you want to do the above, you can just as easily create separate Canvas elements and define a different context for each. A canvas can be passed as an image to another canvas, so the above example could use the rendered content from the c2d and csvg canvas elements as textures for the c3d, and vice versa (assuming your imaginary SVG rendering context has an API to use a Canvas element as an image source). The current implementation of WebKit has what I think is the correct semantics, not because I happen to have implemented it that way. I implemented it that way because I think it's the correct semantic. When you specify a context type that is different from the current type, the current context is detached from the render buffer associated with the Canvas element and therefore that context can no longer be used for rendering. The new context type is then created and attached to the render buffer. If you specify a context type that doesn't exist, the current context is detached and no new one is attached. If you ask for the same context type as is currently defined for the Canvas element, a reference to the same context is returned. I'm not actually sure what happens when you render to a detached context, but clearly we have to define that. I actually don't like the fact that doing a subsequent getContext() returns the same reference. It makes it impossible to know whether or not a context was created. That makes the semantics of what happens with the passed WebGLContextAttributes? The spec now states that on subsequent calls the attributes are ignored. But that makes it hard to know if the attributes you passed were actually used. So there are issues to be resolved. But I feel strongly that a single Canvas element should never be allowed to have multiple active contexts associated with it. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Sun Dec 20 20:50:51 2009 From: cal...@ (Mark Callow) Date: Mon, 21 Dec 2009 13:50:51 +0900 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: References: Message-ID: <4B2EFEAB.4000402@hicorp.co.jp> We should not do anything to encourage the mixing of 2D & 3D rendering via different APIs. The required synchronization between the APIs will kill performance. People should be encouraged to draw everything in their canvas with WebGL. Regards -Mark > On Wed, Dec 16, 2009 at 7:05 PM, Gregg Tavares wrote: > > > 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"); > > Draw3DWorldWith3dContext(c3d); > DrawTextLabelsOfThingsIn3DWith2dContext(c2d); > DrawUIWithSVG(csvg) > > I know that so far WebGL has assumed only 1 context is allowed but > maybe we should get a definitive answer. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From gma...@ Mon Dec 21 11:29:08 2009 From: gma...@ (Gregg Tavares) Date: Mon, 21 Dec 2009 11:29:08 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: <4B2EFEAB.4000402@hicorp.co.jp> References: <4B2EFEAB.4000402@hicorp.co.jp> Message-ID: On Sun, Dec 20, 2009 at 8:50 PM, Mark Callow wrote: > We should not do anything to encourage the mixing of 2D & 3D rendering via > different APIs. The required synchronization between the APIs will kill > performance. People should be encouraged to draw everything in their canvas > with WebGL. > > I think the issue is rather that IF canvas is supposed to allow multiple contexts, then IF WebGL cares about performance it will need its own tag. It's certainly arguable that if the intent of is a "rectangle of pixels with multiple contexts to effect those pixels" then if WebGL doesn't want to follow those rules it does not belong in the canvas tag. Multiple contexts seems like a reasonable design on the canvas tag because it allows the tag to be expanded by new types of contexts. A context for image manipulation, a context for fancier curves, a context for fancier text support, etc... > Regards > > -Mark > > On Wed, Dec 16, 2009 at 7:05 PM, Gregg Tavares wrote: > > > 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"); > > Draw3DWorldWith3dContext(c3d); > DrawTextLabelsOfThingsIn3DWith2dContext(c2d); > DrawUIWithSVG(csvg) > > I know that so far WebGL has assumed only 1 context is allowed but > maybe we should get a definitive answer. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Dec 21 14:33:36 2009 From: cma...@ (Chris Marrin) Date: Mon, 21 Dec 2009 14:33:36 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: References: <4B2EFEAB.4000402@hicorp.co.jp> Message-ID: <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> On Dec 21, 2009, at 11:29 AM, Gregg Tavares wrote: > > > On Sun, Dec 20, 2009 at 8:50 PM, Mark Callow > wrote: > We should not do anything to encourage the mixing of 2D & 3D > rendering via different APIs. The required synchronization between > the APIs will kill performance. People should be encouraged to draw > everything in their canvas with WebGL. > > > I think the issue is rather that IF canvas is supposed to allow > multiple contexts, then IF WebGL cares about performance it will > need its own tag. It's certainly arguable that if the intent of > is a "rectangle of pixels with multiple contexts to effect > those pixels" then if WebGL doesn't want to follow those rules it > does not belong in the canvas tag. I'm not sure what "rules" you're referring to. There are currently no stated rules for the relationship between the canvas (the rectangle of pixels being composited with the page) and the context (the set of API calls and state that control the marking of that rectangle of pixels). Part of our discussions with the HTML 5 group is working out these rules. There are two ways to think of that relationship. There's the "all at once" model, where you can interleave calls from different APIs. This is what several people on this list have cautioned against because of synchronization and other issues. But there's also the "one at a time" model where you create a context with one API, render with it, then toss that context and create one with a different API using the same pixels. That model is a lot more tractable. I think I understand your desire to use multiple APIs on the same pixels, and I think the second model fits that desire. I think it could be well defined. You just have to define what the pixels from one context's API look like when you change to the new API. For instance, when you go from a WebGL context to a 2D context it would be easy to keep the color pixels around. But what happens to the depth buffer? The semantics can be complex so I think we should save this feature for the future. In the meantime we have a well defined one-to-one relationship between canvas elements and contexts. If you want to combine them you simply render to separate canvas elements and then use texImage2D (or the equivalent in the 2D API) and combine them using the rules of the current API. This requires copying the pixels, but I think that's sufficient in the first release. I think another useful conversation is how to share the assets (textures, buffers, programs) between separate contexts of the same type. It would be extremely useful to share assets between WebGL contexts. This is easy to do on Mac, and I think there are versions of Windows where it is possible, too. The semantics can be described, but they can be complex, so I think we should save this feature for a future version as well. ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Mon Dec 21 14:38:42 2009 From: vla...@ (Vladimir Vukicevic) Date: Mon, 21 Dec 2009 14:38:42 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> References: <4B2EFEAB.4000402@hicorp.co.jp> <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> Message-ID: <4B2FF8F2.7080506@mozilla.com> On 12/21/2009 2:33 PM, Chris Marrin wrote: > > On Dec 21, 2009, at 11:29 AM, Gregg Tavares wrote: > >> >> >> On Sun, Dec 20, 2009 at 8:50 PM, Mark Callow >> > wrote: >> >> We should not do anything to encourage the mixing of 2D & 3D >> rendering via different APIs. The required synchronization >> between the APIs will kill performance. People should be >> encouraged to draw everything in their canvas with WebGL. >> >> >> I think the issue is rather that IF canvas is supposed to allow >> multiple contexts, then IF WebGL cares about performance it will need >> its own tag. It's certainly arguable that if the intent of >> is a "rectangle of pixels with multiple contexts to effect those >> pixels" then if WebGL doesn't want to follow those rules it does not >> belong in the canvas tag. > > I'm not sure what "rules" you're referring to. There are currently no > stated rules for the relationship between the canvas (the rectangle of > pixels being composited with the page) and the context (the set of API > calls and state that control the marking of that rectangle of pixels). > Part of our discussions with the HTML 5 group is working out these > rules. There are two ways to think of that relationship. There's the > "all at once" model, where you can interleave calls from different > APIs. This is what several people on this list have cautioned against > because of synchronization and other issues. But there's also the "one > at a time" model where you create a context with one API, render with > it, then toss that context and create one with a different API using > the same pixels. That model is a lot more tractable. > > I think I understand your desire to use multiple APIs on the same > pixels, and I think the second model fits that desire. I think it > could be well defined. You just have to define what the pixels from > one context's API look like when you change to the new API. For > instance, when you go from a WebGL context to a 2D context it would be > easy to keep the color pixels around. But what happens to the depth > buffer? The semantics can be complex so I think we should save this > feature for the future. > > In the meantime we have a well defined one-to-one relationship > between canvas elements and contexts. If you want to combine them you > simply render to separate canvas elements and then use texImage2D (or > the equivalent in the 2D API) and combine them using the rules of the > current API. This requires copying the pixels, but I think that's > sufficient in the first release. I'm pretty against allowing multiple context types on ; I'll state that in html5/whatwg shortly. Chris, I agree with you that you should be able to throw away one context and create another of a different type, but even for that, I'm not sure if there's much value to it. If you want to render using multiple contexts, you can use css to stack elements on top of one another; if you want to /interleave/ rendering, well, I don't think we should support that, and people should texImage2D from the 2D canvas or use similar approaches to get their other-API rendering in. And if you want to throw away one context and start again, you could just create a new element.. - Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Dec 21 15:54:54 2009 From: cma...@ (Chris Marrin) Date: Mon, 21 Dec 2009 15:54:54 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: <4B2FF8F2.7080506@mozilla.com> References: <4B2EFEAB.4000402@hicorp.co.jp> <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> <4B2FF8F2.7080506@mozilla.com> Message-ID: <7E7BE0B9-573C-467B-A85A-5692826E9A2F@apple.com> On Dec 21, 2009, at 2:38 PM, Vladimir Vukicevic wrote: > On 12/21/2009 2:33 PM, Chris Marrin wrote: >> >> >> On Dec 21, 2009, at 11:29 AM, Gregg Tavares wrote: >> >>> >>> >>> On Sun, Dec 20, 2009 at 8:50 PM, Mark Callow >> > wrote: >>> We should not do anything to encourage the mixing of 2D & 3D >>> rendering via different APIs. The required synchronization between >>> the APIs will kill performance. People should be encouraged to >>> draw everything in their canvas with WebGL. >>> >>> >>> I think the issue is rather that IF canvas is supposed to allow >>> multiple contexts, then IF WebGL cares about performance it will >>> need its own tag. It's certainly arguable that if the intent of >>> is a "rectangle of pixels with multiple contexts to >>> effect those pixels" then if WebGL doesn't want to follow those >>> rules it does not belong in the canvas tag. >> >> I'm not sure what "rules" you're referring to. There are currently >> no stated rules for the relationship between the canvas (the >> rectangle of pixels being composited with the page) and the context >> (the set of API calls and state that control the marking of that >> rectangle of pixels). Part of our discussions with the HTML 5 group >> is working out these rules. There are two ways to think of that >> relationship. There's the "all at once" model, where you can >> interleave calls from different APIs. This is what several people >> on this list have cautioned against because of synchronization and >> other issues. But there's also the "one at a time" model where you >> create a context with one API, render with it, then toss that >> context and create one with a different API using the same pixels. >> That model is a lot more tractable. >> >> I think I understand your desire to use multiple APIs on the same >> pixels, and I think the second model fits that desire. I think it >> could be well defined. You just have to define what the pixels from >> one context's API look like when you change to the new API. For >> instance, when you go from a WebGL context to a 2D context it would >> be easy to keep the color pixels around. But what happens to the >> depth buffer? The semantics can be complex so I think we should >> save this feature for the future. >> >> In the meantime we have a well defined one-to-one relationship >> between canvas elements and contexts. If you want to combine them >> you simply render to separate canvas elements and then use >> texImage2D (or the equivalent in the 2D API) and combine them using >> the rules of the current API. This requires copying the pixels, but >> I think that's sufficient in the first release. > > I'm pretty against allowing multiple context types on ; I'll > state that in html5/whatwg shortly. Chris, I agree with you that > you should be able to throw away one context and create another of a > different type, but even for that, I'm not sure if there's much > value to it. If you want to render using multiple contexts, you can > use css to stack elements on top of one another; if you > want to interleave rendering, well, I don't think we should support > that, and people should texImage2D from the 2D canvas or use similar > approaches to get their other-API rendering in. And if you want to > throw away one context and start again, you could just create a new > element.. I think it may be useful to have a semantic in the future where you can preserve the pixels on a canvas when switching between renderers. Imagine a future image processing API. You could do some nice 3D rendering, switch to the image processing API and post-process it, all without having to (conceptually) copy pixels. Maybe an implementation would actually have to copy the pixels from the 3D context, destroy it, create the new renderer and copy the pixels into that. But that would be no worse than making the author do it by hand. And having a semantic for it allows an implementation to be much more efficient when switching, even perhaps avoiding the copy completely. But as I said, the definition of such a thing can wait. For release 1.0 I think we should define the canvas pixels on creation of the WebGL context as containing (0,0,0,1) just like the 2D context (or is it 0,0,0,0?)? ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shi...@ Mon Dec 21 20:38:05 2009 From: shi...@ (Shiki Okasaka) Date: Tue, 22 Dec 2009 13:38:05 +0900 Subject: [Public WebGL] Typed WebGLArray sequence parameter types Message-ID: <2fdcc83a0912212038k4fc63980wc2244d07acfc894d@mail.gmail.com> Is this possible to modify typed WebGLArray sequence parameter types in the IDL definitions as below? * WebGLByteArray: sequence -> sequence * WebGLUnsignedByteArray: sequence -> sequence * WebGLShortArray: sequence -> sequence * WebGLUnsignedShortArray: sequence -> sequence This change would make the generated interfaces for statically typed languages (e.g. Java) more useful. Note currently Web IDL does not have a primitive type for 8-bit signed integer values. If it is useful for WebGL, maybe we can propose an addition of it to Web IDL as Geolocation WG requested to add 'double' in addition to 'float' [0]. [0] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0960.html Best, - Shiki Okasaka ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Dec 21 22:35:30 2009 From: vla...@ (Vladimir Vukicevic) Date: Mon, 21 Dec 2009 22:35:30 -0800 Subject: [Public WebGL] Typed WebGLArray sequence parameter types In-Reply-To: <2fdcc83a0912212038k4fc63980wc2244d07acfc894d@mail.gmail.com> References: <2fdcc83a0912212038k4fc63980wc2244d07acfc894d@mail.gmail.com> Message-ID: <4B3068B2.1000104@mozilla.com> On 12/21/2009 8:38 PM, Shiki Okasaka wrote: > Is this possible to modify typed WebGLArray sequence parameter types > in the IDL definitions as below? > > * WebGLByteArray: > sequence -> sequence > * WebGLUnsignedByteArray: > sequence -> sequence > * WebGLShortArray: > sequence -> sequence > * WebGLUnsignedShortArray: > sequence -> sequence > > This change would make the generated interfaces for statically typed > languages (e.g. Java) more useful. > > Note currently Web IDL does not have a primitive type for 8-bit signed > integer values. If it is useful for WebGL, maybe we can propose an > addition of it to Web IDL as Geolocation WG requested to add 'double' > in addition to 'float' [0]. > Yep, that's the main reason why long/unsigned long are used instead of octet -- if octet was used, then it becomes impossible to actually specify signed 8-bit integers. For short, we decided to follow the same convention. However, maybe a workaround would be to add a typedef somewhere for our own signed_octet type, by default typedef'd to unsigned long, but with a statement in the spec saying that this should be a signed 8 bit type if the language supports it? - Vlad ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Dec 21 23:08:35 2009 From: vla...@ (Vladimir Vukicevic) Date: Mon, 21 Dec 2009 23:08:35 -0800 Subject: [Public WebGL] String constructors for arrays? Message-ID: <4B307073.2060006@mozilla.com> I was reading Ilmari's post here -- http://fhtr.blogspot.com/2009/12/3d-models-and-parsing-binary-data-with.html -- and thought that it might be interesting to supporting constructors on the WebGL array types that take a string as input data. The 8-bit types would take only the low 8 bits of each character value, and for completeness the 32-bit types could sign-extend to 32 bits. This would make it much easier to work with data read from the net until we have better native support for interacting with truly binary data, because dealing with it in string form is pretty common. Feature creep or useful? - Vlad ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From shi...@ Mon Dec 21 23:16:30 2009 From: shi...@ (Shiki Okasaka) Date: Tue, 22 Dec 2009 16:16:30 +0900 Subject: [Public WebGL] Typed WebGLArray sequence parameter types In-Reply-To: <4B3068B2.1000104@mozilla.com> References: <2fdcc83a0912212038k4fc63980wc2244d07acfc894d@mail.gmail.com> <4B3068B2.1000104@mozilla.com> Message-ID: <2fdcc83a0912212316h4018c2fbo9d1f84f804b7bb8a@mail.gmail.com> On Tue, Dec 22, 2009 at 3:35 PM, Vladimir Vukicevic wrote: > On 12/21/2009 8:38 PM, Shiki Okasaka wrote: >> >> Is this possible to modify typed WebGLArray sequence parameter types >> in the IDL definitions as below? >> >> * WebGLByteArray: >> ? ?sequence ?-> ?sequence >> * WebGLUnsignedByteArray: >> ? ?sequence ?-> ?sequence >> * WebGLShortArray: >> ? ?sequence ?-> ?sequence >> * WebGLUnsignedShortArray: >> ? ?sequence ?-> ?sequence >> >> This change would make the generated interfaces for statically typed >> languages (e.g. Java) more useful. >> >> Note currently Web IDL does not have a primitive type for 8-bit signed >> integer values. If it is useful for WebGL, maybe we can propose an >> addition of it to Web IDL as Geolocation WG requested to add 'double' >> in addition to 'float' [0]. >> > > Yep, that's the main reason why long/unsigned long are used instead of octet > -- if octet was used, then it becomes impossible to actually specify signed > 8-bit integers. ?For short, we decided to follow the same convention. > ?However, maybe a workaround would be to add a typedef somewhere for our own > signed_octet type, by default typedef'd to unsigned long, but with a > statement in the spec saying that this should be a signed 8 bit type if the > language supports it? It would be very practical. How about moving typedef names to the top level from WebGLRenderingContext, which are not allowed in Web IDL grammar anyway, and adding typedef names GLbyte, GLubyte, GLshort, and GLushort to use these entirely in the WebGL spec? - Shiki > > ? ?- Vlad > > ----------------------------------------------------------- > You are currently subscribe to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From exc...@ Tue Dec 22 03:24:08 2009 From: exc...@ (Philip Taylor) Date: Tue, 22 Dec 2009 11:24:08 +0000 Subject: [Public WebGL] String constructors for arrays? In-Reply-To: <4B307073.2060006@mozilla.com> References: <4B307073.2060006@mozilla.com> Message-ID: On Tue, Dec 22, 2009 at 7:08 AM, Vladimir Vukicevic wrote: > I was reading Ilmari's post here -- > http://fhtr.blogspot.com/2009/12/3d-models-and-parsing-binary-data-with.html > -- and thought that it might be interesting to supporting constructors on > the WebGL array types that take a string as input data. ?The 8-bit types > would take only the low 8 bits of each character value, and for completeness > the 32-bit types could sign-extend to 32 bits. ?This would make it much > easier to work with data read from the net until we have better native > support for interacting with truly binary data, because dealing with it in > string form is pretty common. ?Feature creep or useful? What about big-endian vs little-endian? Signed vs unsigned? Floats, half-floats, truncated 16-bit floats, fixed point numbers? It seems like this API would be either very specific to a handful of data representations (and therefore useless when people want their data to be very slightly different), or it would be a large complex general-purpose binary number parsing system (and therefore harder to understand and use, and it shouldn't be defined as part of a canvas context because it's out of scope). With a very rough test like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/337 (parsing and summing 4-byte ints), I see speeds of about 2 million ints/sec in Firefox 3.5, and 14 million ints/sec in Opera 10.50 - so it's possible for pure JS to be pretty fast, and the bottleneck is likely to be network bandwidth. So I'd be happier to keep binary parsing as plain JS code, and focus any browser implementation effort on optimising JS engines for this kind of use, since that minimises spec complexity and maximises flexibility for authors. -- Philip Taylor excors...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Tue Dec 22 09:28:18 2009 From: kbr...@ (Kenneth Russell) Date: Tue, 22 Dec 2009 09:28:18 -0800 Subject: [Public WebGL] Typed WebGLArray sequence parameter types In-Reply-To: <4B3068B2.1000104@mozilla.com> References: <2fdcc83a0912212038k4fc63980wc2244d07acfc894d@mail.gmail.com> <4B3068B2.1000104@mozilla.com> Message-ID: <921bb10912220928i229af3d5tff970b5895fd0edc@mail.gmail.com> On Mon, Dec 21, 2009 at 10:35 PM, Vladimir Vukicevic wrote: > On 12/21/2009 8:38 PM, Shiki Okasaka wrote: >> >> Is this possible to modify typed WebGLArray sequence parameter types >> in the IDL definitions as below? >> >> * WebGLByteArray: >> ? ?sequence ?-> ?sequence >> * WebGLUnsignedByteArray: >> ? ?sequence ?-> ?sequence >> * WebGLShortArray: >> ? ?sequence ?-> ?sequence >> * WebGLUnsignedShortArray: >> ? ?sequence ?-> ?sequence >> >> This change would make the generated interfaces for statically typed >> languages (e.g. Java) more useful. >> >> Note currently Web IDL does not have a primitive type for 8-bit signed >> integer values. If it is useful for WebGL, maybe we can propose an >> addition of it to Web IDL as Geolocation WG requested to add 'double' >> in addition to 'float' [0]. >> > > Yep, that's the main reason why long/unsigned long are used instead of octet > -- if octet was used, then it becomes impossible to actually specify signed > 8-bit integers. ?For short, we decided to follow the same convention. > ?However, maybe a workaround would be to add a typedef somewhere for our own > signed_octet type, by default typedef'd to unsigned long, but with a > statement in the spec saying that this should be a signed 8 bit type if the > language supports it? Sounds like a good workaround. -Ken ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Tue Dec 22 11:43:00 2009 From: cma...@ (Chris Marrin) Date: Tue, 22 Dec 2009 11:43:00 -0800 Subject: [Public WebGL] String constructors for arrays? In-Reply-To: <4B307073.2060006@mozilla.com> References: <4B307073.2060006@mozilla.com> Message-ID: <3EF23B25-B3E1-4AF3-96FF-1E93DA3AA0D2@apple.com> On Dec 21, 2009, at 11:08 PM, Vladimir Vukicevic wrote: > I was reading Ilmari's post here -- http://fhtr.blogspot.com/2009/12/3d-models-and-parsing-binary-data-with.html > -- and thought that it might be interesting to supporting > constructors on the WebGL array types that take a string as input > data. The 8-bit types would take only the low 8 bits of each > character value, and for completeness the 32-bit types could sign- > extend to 32 bits. This would make it much easier to work with data > read from the net until we have better native support for > interacting with truly binary data, because dealing with it in > string form is pretty common. Feature creep or useful? I don't think we should add stopgap features like this. Ilmari has already proven that he can get some nice speedups with today's feature set. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Tue Dec 22 17:54:51 2009 From: kbr...@ (Kenneth Russell) Date: Tue, 22 Dec 2009 17:54:51 -0800 Subject: [Public WebGL] WebGLContextAttributes Message-ID: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> The WebGLContextAttributes interface currently uses DOMStrings for the values passed to the NameSetter and returned from the NameGetter. Should these be type "any" instead? Currently creating such an object would be unnatural in JavaScript: gl = c.getContext("experimental-webgl", { antialias: "false", stencil: "false" }); It would be more natural to write: gl = c.getContext("experimental-webgl", { antialias: false, stencil: false }); We would need to specify the type of each value stored in the dictionary. This would make this interface behave more like the various get methods which return type "any". -Ken ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Tue Dec 22 22:50:47 2009 From: cma...@ (Chris Marrin) Date: Tue, 22 Dec 2009 22:50:47 -0800 Subject: [Public WebGL] WebGLContextAttributes In-Reply-To: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> References: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> Message-ID: <26A5743E-C856-4A59-A21D-E80BD63404C2@apple.com> On Dec 22, 2009, at 5:54 PM, Kenneth Russell wrote: > The WebGLContextAttributes interface currently uses DOMStrings for the > values passed to the NameSetter and returned from the NameGetter. > Should these be type "any" instead? Currently creating such an object > would be unnatural in JavaScript: > > gl = c.getContext("experimental-webgl", > { antialias: "false", > stencil: "false" }); > > It would be more natural to write: > > gl = c.getContext("experimental-webgl", > { antialias: false, > stencil: false }); > > We would need to specify the type of each value stored in the dictionary. > > This would make this interface behave more like the various get > methods which return type "any". I would have no problem with this. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Wed Dec 23 02:53:29 2009 From: gma...@ (Gregg Tavares) Date: Wed, 23 Dec 2009 02:53:29 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: <7E7BE0B9-573C-467B-A85A-5692826E9A2F@apple.com> References: <4B2EFEAB.4000402@hicorp.co.jp> <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> <4B2FF8F2.7080506@mozilla.com> <7E7BE0B9-573C-467B-A85A-5692826E9A2F@apple.com> Message-ID: Having more than one context has apparently been around since 2006 http://my.opera.com/WebApplications/blog/show.dml/200788 And the HTML5 spec certainly doesn't discourage multiple contexts by design. It seems like that's the design they intended as it's by far the most useful. That suggests a few different paths 1) Support multiple contexts including webgl. I certainly understand the issues here though it wouldn't be all that hard to implement it in such a way that there is no performance penalty if not used. WebGL already has to support canvas.toDataURL so the code to support that could easily be called if a draw function in a different context is used and visa-versa. 2) Don't support multiple contexts. That seems like bad choice given that there is already precedent and it's extremely useful. If canvas is by design, a bucket of pixels then it certainly makes sense that it would be possible to effect those pixels in multiple ways and as more ways come up use them all together. 3) Switch to a tag instead of canvas. I suspect this suggestion will be unpopular but it seems to me that if canvas has a model and webgl is not willing to support that model than it doesn't belong in canvas. Having it's own tag would leave the canvas tag's model as is and let webgl do whatever it wants (no read back, no strange getContext that works differently on second call, etc...) Of course all this assumes that multiple contexts is the best thing for canvas. I think it's very arguable that it is. On Mon, Dec 21, 2009 at 3:54 PM, Chris Marrin wrote: > > On Dec 21, 2009, at 2:38 PM, Vladimir Vukicevic wrote: > > On 12/21/2009 2:33 PM, Chris Marrin wrote: > > > On Dec 21, 2009, at 11:29 AM, Gregg Tavares wrote: > > > > On Sun, Dec 20, 2009 at 8:50 PM, Mark Callow wrote: > >> We should not do anything to encourage the mixing of 2D & 3D rendering via >> different APIs. The required synchronization between the APIs will kill >> performance. People should be encouraged to draw everything in their canvas >> with WebGL. >> >> > I think the issue is rather that IF canvas is supposed to allow multiple > contexts, then IF WebGL cares about performance it will need its own tag. > It's certainly arguable that if the intent of is a "rectangle of > pixels with multiple contexts to effect those pixels" then if WebGL doesn't > want to follow those rules it does not belong in the canvas tag. > > > I'm not sure what "rules" you're referring to. There are currently no > stated rules for the relationship between the canvas (the rectangle of > pixels being composited with the page) and the context (the set of API calls > and state that control the marking of that rectangle of pixels). Part of our > discussions with the HTML 5 group is working out these rules. There are two > ways to think of that relationship. There's the "all at once" model, where > you can interleave calls from different APIs. This is what several people on > this list have cautioned against because of synchronization and other > issues. But there's also the "one at a time" model where you create a > context with one API, render with it, then toss that context and create one > with a different API using the same pixels. That model is a lot more > tractable. > > I think I understand your desire to use multiple APIs on the same pixels, > and I think the second model fits that desire. I think it could be well > defined. You just have to define what the pixels from one context's API look > like when you change to the new API. For instance, when you go from a WebGL > context to a 2D context it would be easy to keep the color pixels around. > But what happens to the depth buffer? The semantics can be complex so I > think we should save this feature for the future. > > In the meantime we have a well defined one-to-one relationship between > canvas elements and contexts. If you want to combine them you simply render > to separate canvas elements and then use texImage2D (or the equivalent in > the 2D API) and combine them using the rules of the current API. This > requires copying the pixels, but I think that's sufficient in the first > release. > > > I'm pretty against allowing multiple context types on ; I'll state > that in html5/whatwg shortly. Chris, I agree with you that you should be > able to throw away one context and create another of a different type, but > even for that, I'm not sure if there's much value to it. If you want to > render using multiple contexts, you can use css to stack elements > on top of one another; if you want to *interleave* rendering, well, I > don't think we should support that, and people should texImage2D from the 2D > canvas or use similar approaches to get their other-API rendering in. And > if you want to throw away one context and start again, you could just create > a new element.. > > > I think it may be useful to have a semantic in the future where you can > preserve the pixels on a canvas when switching between renderers. Imagine a > future image processing API. You could do some nice 3D rendering, switch to > the image processing API and post-process it, all without having to > (conceptually) copy pixels. Maybe an implementation would actually have to > copy the pixels from the 3D context, destroy it, create the new renderer and > copy the pixels into that. But that would be no worse than making the author > do it by hand. And having a semantic for it allows an implementation to be > much more efficient when switching, even perhaps avoiding the copy > completely. > > But as I said, the definition of such a thing can wait. For release 1.0 I > think we should define the canvas pixels on creation of the WebGL context as > containing (0,0,0,1) just like the 2D context (or is it 0,0,0,0?)? > > ----- > ~Chris > cmarrin...@ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From exc...@ Wed Dec 23 03:13:36 2009 From: exc...@ (Philip Taylor) Date: Wed, 23 Dec 2009 11:13:36 +0000 Subject: [Public WebGL] WebGLContextAttributes In-Reply-To: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> References: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> Message-ID: On Wed, Dec 23, 2009 at 1:54 AM, Kenneth Russell wrote: > The WebGLContextAttributes interface currently uses DOMStrings for the > values passed to the NameSetter and returned from the NameGetter. > Should these be type "any" instead? Currently creating such an object > would be unnatural in JavaScript: > > gl = c.getContext("experimental-webgl", > ? ?{ antialias: "false", > ? ? ?stencil: "false" }); I believe that is not allowed by the current spec, and will result in a TypeError. It seems the intention of WebGL is that the second argument is a WebGLContextAttributes object (though the WebGL spec currently lacks the IDL defining that), in which case http://dev.w3.org/2006/webapi/WebIDL/#es-interface is relevant. The "{...}" object is not a host object, and WebGLContextAttributes doesn't satisfy the criteria for allowing native object implementations, so this won't work. You'd have to say var attr = new WebGLContextAttributes(); attr.antialias = "false"; etc Then (with the current definitions) you could already say attr.antialias = false; because the NameSetter takes a DOMString argument, so the value on the JS side will be automatically converted to a string (in this case "false"). -- Philip Taylor excors...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Wed Dec 23 06:36:35 2009 From: kbr...@ (Kenneth Russell) Date: Wed, 23 Dec 2009 06:36:35 -0800 Subject: [Public WebGL] WebGLContextAttributes In-Reply-To: References: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> Message-ID: <921bb10912230636x40613ffdge7a4b161b3c88103@mail.gmail.com> On Wed, Dec 23, 2009 at 3:13 AM, Philip Taylor wrote: > On Wed, Dec 23, 2009 at 1:54 AM, Kenneth Russell wrote: >> The WebGLContextAttributes interface currently uses DOMStrings for the >> values passed to the NameSetter and returned from the NameGetter. >> Should these be type "any" instead? Currently creating such an object >> would be unnatural in JavaScript: >> >> gl = c.getContext("experimental-webgl", >> ? ?{ antialias: "false", >> ? ? ?stencil: "false" }); > > I believe that is not allowed by the current spec, and will result in > a TypeError. It seems the intention of WebGL is that the second > argument is a WebGLContextAttributes object (though the WebGL spec > currently lacks the IDL defining that), in which case > http://dev.w3.org/2006/webapi/WebIDL/#es-interface is relevant. The > "{...}" object is not a host object, and WebGLContextAttributes > doesn't satisfy the criteria for allowing native object > implementations, so this won't work. > > You'd have to say > > ?var attr = new WebGLContextAttributes(); > ?attr.antialias = "false"; > ?etc > > Then (with the current definitions) you could already say > > ?attr.antialias = false; > > because the NameSetter takes a DOMString argument, so the value on the > JS side will be automatically converted to a string (in this case > "false"). The WebGL working group's intent with this interface was to allow a JavaScript object literal to be passed in for this argument. (Someone please correct me if I'm misspeaking.) How would we need to change the IDL to allow this? From looking at the WebIDL spec you pointed to, it looks like the issue is the presence of the setters / getters, and that this would satisfy the requirements: interface WebGLContextAttributes { attribute boolean alpha; attribute boolean depth; attribute boolean stencil; attribute boolean antialias; attribute boolean premultipliedAlpha; }; By the way, I and perhaps others have been looking at http://www.w3.org/TR/WebIDL/ , which it looks like is out of date. -Ken ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From exc...@ Wed Dec 23 07:17:25 2009 From: exc...@ (Philip Taylor) Date: Wed, 23 Dec 2009 15:17:25 +0000 Subject: [Public WebGL] WebGLContextAttributes In-Reply-To: <921bb10912230636x40613ffdge7a4b161b3c88103@mail.gmail.com> References: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> <921bb10912230636x40613ffdge7a4b161b3c88103@mail.gmail.com> Message-ID: On Wed, Dec 23, 2009 at 2:36 PM, Kenneth Russell wrote: > [...] > The WebGL working group's intent with this interface was to allow a > JavaScript object literal to be passed in for this argument. (Someone > please correct me if I'm misspeaking.) > > How would we need to change the IDL to allow this? From looking at the > WebIDL spec you pointed to, it looks like the issue is the presence of > the setters / getters, and that this would satisfy the requirements: > > ? ?interface WebGLContextAttributes { > ? ? ? ?attribute boolean alpha; > ? ? ? ?attribute boolean depth; > ? ? ? ?attribute boolean stencil; > ? ? ? ?attribute boolean antialias; > ? ? ? ?attribute boolean premultipliedAlpha; > ? ?}; Going by , I think you'd need "[Callback] interface WebGLContextAttributes { ...as above... }" and then it might be right. But I'm definitely not an expert on WebIDL, so it'd probably be good to ask someone who is :-) One difficulty with that context attribute syntax is what happens when someone writes: c.getContext('webgl', { get alpha() { alert('alpha'); return false; } }); because the getter function will be called whenever the implementation tries to retrieve the attribute value, and it ought to be specified when and how often that happens. (e.g. is it only called during the getContext call, or could it be run at an arbitrary time in the future?) I believe there have been similar discussions about how to design an API with key/value pairs in the W3C public-webapps mailing list (related to selector namespaces) but I don't know if there was any conclusion about good or bad ways to do it. > By the way, I and perhaps others have been looking at > http://www.w3.org/TR/WebIDL/ , which it looks like is out of date. Yeah, I think it'd be better to use the latest editor's draft rather than the year-old snapshot, since it's likely to be much more correct and stable. HTML5 already uses the syntax and definitions from the editor's draft. -- Philip Taylor excors...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Wed Dec 23 09:16:01 2009 From: kbr...@ (Kenneth Russell) Date: Wed, 23 Dec 2009 09:16:01 -0800 Subject: [Public WebGL] WebGLContextAttributes In-Reply-To: References: <921bb10912221754j33267e7fh4489e83861619a5d@mail.gmail.com> <921bb10912230636x40613ffdge7a4b161b3c88103@mail.gmail.com> Message-ID: <921bb10912230916v693d53a3n5552186a78c969be@mail.gmail.com> On Wed, Dec 23, 2009 at 7:17 AM, Philip Taylor wrote: > On Wed, Dec 23, 2009 at 2:36 PM, Kenneth Russell wrote: >> [...] >> The WebGL working group's intent with this interface was to allow a >> JavaScript object literal to be passed in for this argument. (Someone >> please correct me if I'm misspeaking.) >> >> How would we need to change the IDL to allow this? From looking at the >> WebIDL spec you pointed to, it looks like the issue is the presence of >> the setters / getters, and that this would satisfy the requirements: >> >> ? ?interface WebGLContextAttributes { >> ? ? ? ?attribute boolean alpha; >> ? ? ? ?attribute boolean depth; >> ? ? ? ?attribute boolean stencil; >> ? ? ? ?attribute boolean antialias; >> ? ? ? ?attribute boolean premultipliedAlpha; >> ? ?}; > > Going by , I > think you'd need "[Callback] interface WebGLContextAttributes { ...as > above... }" and then it might be right. Right, I see that now. > But I'm definitely not an > expert on WebIDL, so it'd probably be good to ask someone who is :-) Neither am I. > One difficulty with that context attribute syntax is what happens when > someone writes: > > ?c.getContext('webgl', { get alpha() { alert('alpha'); return false; } }); > > because the getter function will be called whenever the implementation > tries to retrieve the attribute value, and it ought to be specified > when and how often that happens. (e.g. is it only called during the > getContext call, or could it be run at an arbitrary time in the > future?) It wouldn't be a problem to specify that its properties are only fetched during the getContext call. Does anyone have any comments about changing the WebGLContextAttributes specification to the following? [Callback] interface WebGLContextAttributes { attribute boolean alpha; attribute boolean depth; attribute boolean stencil; attribute boolean antialias; attribute boolean premultipliedAlpha; }; We could add a sidebar example showing that the intent is that a JavaScript object literal can be passed in. Hopefully this would work reasonably well for other language bindings. > I believe there have been similar discussions about how to design an > API with key/value pairs in the W3C public-webapps mailing list > (related to selector namespaces) but I don't know if there was any > conclusion about good or bad ways to do it. I couldn't find anything about this with a few quick searches, but if you can dig up any pointers please send them along. -Ken >> By the way, I and perhaps others have been looking at >> http://www.w3.org/TR/WebIDL/ , which it looks like is out of date. > > Yeah, I think it'd be better to use the latest editor's draft rather > than the year-old snapshot, since it's likely to be much more correct > and stable. HTML5 already uses the syntax and definitions from the > editor's draft. > > -- > Philip Taylor > excors...@ > ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cha...@ Wed Dec 23 09:18:14 2009 From: cha...@ (Charles Ying) Date: Wed, 23 Dec 2009 09:18:14 -0800 Subject: [Public WebGL] WebGL Shader Toy by iq/rgba Message-ID: <3db207a40912230918x3247c39brf63137db16ffbb3e@mail.gmail.com> iq of demoscene group rgba posted a WebGL Shader Toy REPL on his site on Monday. http://www.iquilezles.org/apps/shadertoy It's pretty insane. It has all of the latest GPU shader demos (including Slisesix, Kinderpainter and Chocolux) from the demoscene all in one fun page. You can also edit the shaders live, and make your own... and see iq/rgba's ray marching shader code in action. WebKit has some text editor rendering bugs, but still, really cool stuff. The link from pouet.net (demoscene community site) http://pouet.net/prod.php?which=54180 Best, Charles ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Wed Dec 23 10:54:53 2009 From: cma...@ (Chris Marrin) Date: Wed, 23 Dec 2009 10:54:53 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: References: <4B2EFEAB.4000402@hicorp.co.jp> <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> <4B2FF8F2.7080506@mozilla.com> <7E7BE0B9-573C-467B-A85A-5692826E9A2F@apple.com> Message-ID: <35523F5C-763A-4F95-9539-66CA9B91B472@apple.com> On Dec 23, 2009, at 2:53 AM, Gregg Tavares wrote: > Having more than one context has apparently been around since 2006 > > http://my.opera.com/WebApplications/blog/show.dml/200788 > > And the HTML5 spec certainly doesn't discourage multiple contexts by design. > > It seems like that's the design they intended as it's by far the most useful. No it doesn't, but it also doesn't mention what happens when you attempt to getContext on two different context types. We need to help the HTML5 working group define that. Several people here have stated the difficulties with attempting to render to a single canvas with multiple APIs. > > That suggests a few different paths > > 1) Support multiple contexts including webgl. > > I certainly understand the issues here though it wouldn't be all that hard to implement it in such a way that there is no performance penalty if not used. WebGL already has to support canvas.toDataURL so the code to support that could easily be called if a draw function in a different context is used and visa-versa. > > 2) Don't support multiple contexts. > > That seems like bad choice given that there is already precedent and it's extremely useful. If canvas is by design, a bucket of pixels then it certainly makes sense that it would be possible to effect those pixels in multiple ways and as more ways come up use them all together. It would be quite useful to this discussion to understand that API better. Have you used it to understand how well it works and where its pitfalls are? Perhaps someone from Opera can enlighten us about the implementation. > > 3) Switch to a tag instead of canvas. > > I suspect this suggestion will be unpopular but it seems to me that if canvas has a model and webgl is not willing to support that model than it doesn't belong in canvas. Canvas DOESN'T have a model. In the 3 years since Opera created their proprietary API have they gone to the W3C to propose defining multiple contexts in the Canvas element? If so, then we have a basis for discussion. If not, we need to do that definition. My strong recommendation is to disallow multiple contexts. > > Having it's own tag would leave the canvas tag's model as is and let webgl do whatever it wants (no read back, no strange getContext that works differently on second call, etc...) WebGL fits very well in the Canvas model, as evidenced by 3 implementations (and hopefully soon to be a 4th) on 3 desktop platforms and at least one mobile platform. > > Of course all this assumes that multiple contexts is the best thing for canvas. I think it's very arguable that it is. I think it's arguable, too, which is why we're arguing :-) I think it is a bad idea, because there have been experts here that have cautioned against it, and because of my own experience attempting to use multiple graphics APIs on a single surface. But most of all I think it's a bad idea because it would take work to define it and I don't believe we should spend that time in the first release. It's much easier to extend capabilities in a future version than to constrain a feature in the future. ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Dec 23 11:20:10 2009 From: gma...@ (Gregg Tavares) Date: Wed, 23 Dec 2009 11:20:10 -0800 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: <35523F5C-763A-4F95-9539-66CA9B91B472@apple.com> References: <4B2EFEAB.4000402@hicorp.co.jp> <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> <4B2FF8F2.7080506@mozilla.com> <7E7BE0B9-573C-467B-A85A-5692826E9A2F@apple.com> <35523F5C-763A-4F95-9539-66CA9B91B472@apple.com> Message-ID: On Wed, Dec 23, 2009 at 10:54 AM, Chris Marrin wrote: > > On Dec 23, 2009, at 2:53 AM, Gregg Tavares wrote: > > Having more than one context has apparently been around since 2006 > > http://my.opera.com/WebApplications/blog/show.dml/200788 > > And the HTML5 spec certainly doesn't discourage multiple contexts by > design. > > It seems like that's the design they intended as it's by far the most > useful. > > > No it doesn't, but it also doesn't mention what happens when you attempt to > getContext on two different context types. We need to help the HTML5 working > group define that. Several people here have stated the difficulties with > attempting to render to a single canvas with multiple APIs. > > > That suggests a few different paths > > 1) Support multiple contexts including webgl. > > I certainly understand the issues here though it wouldn't be all that hard > to implement it in such a way that there is no performance penalty if not > used. WebGL already has to support canvas.toDataURL so the code to support > that could easily be called if a draw function in a different context is > used and visa-versa. > > 2) Don't support multiple contexts. > > That seems like bad choice given that there is already precedent and it's > extremely useful. If canvas is by design, a bucket of pixels then it > certainly makes sense that it would be possible to effect those pixels in > multiple ways and as more ways come up use them all together. > > > It would be quite useful to this discussion to understand that API better. > Have you used it to understand how well it works and where its pitfalls are? > Perhaps someone from Opera can enlighten us about the implementation. > > > 3) Switch to a tag instead of canvas. > > I suspect this suggestion will be unpopular but it seems to me that if > canvas has a model and webgl is not willing to support that model than it > doesn't belong in canvas. > > > Canvas DOESN'T have a model. In the 3 years since Opera created their > proprietary API have they gone to the W3C to propose defining multiple > contexts in the Canvas element? If so, then we have a basis for discussion. > If not, we need to do that definition. My strong recommendation is to > disallow multiple contexts. > I don't follow the logic here? Which OS doesn't allow someone to use any API they want to draw to a window? Which system doesn't allow you to use any code you want to draw to a rectangle of pixels? Maybe I'm reading something into it but it seems like allowing multiple contexts as the normal thing to do and not allowing multiple contexts is only being advocated because it's hard for WebGL which doesn't seem like it should be the deciding factor. Rather then limit the usefulness of canvas by making it not allowed to have multiple contexts because of WebGL, if WebGL can't share then it doesn't belong in canvas. I'd even go so far as to say that if the designers of canvas wanted to enforce only 1 context they would have designed it to make it impossible to specify more than one such as var api = document.getElementById("foo").getApi(); Instead the API clearly wasn't designed to enforce a single context which suggests that either the creators of canvas choose a poor design or that they intended multiple contexts. I happen to be assuming the later because it's actually extremely useful to allow multiple contexts. > > > Having it's own tag would leave the canvas tag's model as is and let webgl > do whatever it wants (no read back, no strange getContext that works > differently on second call, etc...) > > > WebGL fits very well in the Canvas model, as evidenced by 3 implementations > (and hopefully soon to be a 4th) on 3 desktop platforms and at least one > mobile platform. > > > Of course all this assumes that multiple contexts is the best thing for > canvas. I think it's very arguable that it is. > > > I think it's arguable, too, which is why we're arguing :-) > > I think it is a bad idea, because there have been experts here that have > cautioned against it, and because of my own experience attempting to use > multiple graphics APIs on a single surface. But most of all I think it's a > bad idea because it would take work to define it and I don't believe we > should spend that time in the first release. It's much easier to extend > capabilities in a future version than to constrain a feature in the future. > > ----- > ~Chris > cmarrin...@ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From car...@ Wed Dec 23 12:34:30 2009 From: car...@ (Carl van Heezik) Date: Wed, 23 Dec 2009 21:34:30 +0100 Subject: [Public WebGL] Some WebGL draft feedback In-Reply-To: <35523F5C-763A-4F95-9539-66CA9B91B472@apple.com> References: <4B2EFEAB.4000402@hicorp.co.jp> <232D3496-5733-48BA-98AA-A1EF5F0DA3AE@apple.com> <4B2FF8F2.7080506@mozilla.com> <7E7BE0B9-573C-467B-A85A-5692826E9A2F@apple.com> <35523F5C-763A-4F95-9539-66CA9B91B472@apple.com> Message-ID: <90B8236C088D42F2A8483A1AA3CB7235@hp8510w> Chris, I have some questions about the