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

Re: [Public WebGL] Some WebGL draft feedback

On 12/23/09 11:53 AM, Gregg Tavares wrote:
Having more than one context has apparently been around since 2006


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.

The opera-2dgame context was something I added because it was required to move some demos we had in a technology similar to <canvas> to <canvas>. It does not say much about the intent of the HTML5 spec.

Almost all of the functionality of that context has since been added to the main 2d context.

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.

The only reliable way I see of doing that is to have some kind of present function which copies the pixels to the <canvas>. Doing that would make writing webgl content more complicated and potentially make it much harder to write an implementation which performs well.

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 might be OK for us to drop opera-2dgame if it is not widely used, have to check that though. Most of the functionality from opera-2dgame is in 2d anyway.
It would also be possible to distinguish between "main" contexts and "extension" contexts and just not allow multiple "main" contexts. I would say opera-2dgame is an extension to 2d.

3) Switch to a <webgl> 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 <cmarrin@apple.com <mailto:cmarrin@apple.com>> 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
    <callow_mark@hicorp.co.jp <mailto:callow_mark@hicorp.co.jp>> 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 <canvas> 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 <canvas>; 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 <canvas> 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 <canvas> 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?)…

    cmarrin@apple.com <mailto: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: