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

Re: [Public WebGL] Some WebGL draft feedback



On Dec 16, 2009, at 7:18 PM, Gregg Tavares wrote:

> On Wed, Dec 16, 2009 at 7:05 PM, Gregg Tavares <gman@google.com> wrote:
>> From: Philip Taylor <excors@gmail.com>
>> Some comments about the current draft (up to section 5.2):
>> 
>> About getContext(): I don't understand what should happen in the
>> following cases:
>> 
>>  var a = canvas.getContext('webgl');
>>  var b = canvas.getContext('2d');
>>  var c = canvas.getContext('webgl');
>>  // Is a == c now?
>>  // Are the WebGL contents still shown on the page?
>> 
>>  var a = canvas.getContext('2d');
>>  var b = canvas.getContext('webgl');
>>  a.fillRect(0, 0, 100, 100);
>>  // Does this rectangle get drawn or displayed anywhere?
>> 
>> Detaching the WebGL context when getContext(different-string) is
>> called will prevent a useful extension point - e.g. Opera has
>> getContext('opera-2dgame') which returns a context with a few extra
>> functions that interact with the normal 2D context, and a similar
>> model could be useful to provide extensions to the WebGL context.
>> 
>> The getContext definition seems to differ significantly from the
>> canvas model described by HTML5 - in the HTML5 view of things, the
>> canvas has a single bitmap (which gets rendered to the display, and
>> returned by toDataURL) plus any number of contexts that might read and
>> modify that bitmap. Is WebGL fundamentally incompatible with that
>> model (because of performance or implementation complexity or
>> something)? WebGL should work with the HTML WG to make sure they end
>> up specifying compatible things (and to make sure the model should
>> work with future new canvas contexts).
>> (http://www.w3.org/Bugs/Public/show_bug.cgi?id=8476 is a relevant
>> place on the HTML WG side.)
>> 
>> I don't know a good solution for these issues, but I think there is a
>> problem that needs to be discussed and solved.
>> 
> 
> I agree. It's not at all clear from the HTML5 spec if you are supposed
> to be allowed to get multiple different contexts to the same canvas
> (or else I missed that part of the spec that makes that clear)
> 
> This seems like a valid thing to want to do.
> 
> var c3d = canvas.getContext("webgl");
> var c2d = canvas.getContext("2d");
> var csvg = canvas.getContext("svg");
> 
> 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@apple.com




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