[Public WebGL] using the same context with multiple canvases

Gregg Tavares (社用) [email protected]
Tue Dec 18 23:17:21 PST 2012


On Wed, Dec 19, 2012 at 11:16 AM, Gregg Tavares (社用) <[email protected]>wrote:

>
>
>
> On Wed, Dec 19, 2012 at 6:31 AM, Ian Hickson <[email protected]> wrote:
>
>> On Tue, 18 Dec 2012, Florian Bösch wrote:
>> > On Tue, Dec 18, 2012 at 8:13 PM, Ian Hickson <[email protected]> wrote:
>> > >
>> > > And then if you want to draw to a canvas instead of an off-screen
>> > > buffer, you just use a Canvas instead of a DrawingBuffer.
>> >
>> > So we're gonna get a document.createElement('canvas', {antialias:true,
>> > alpha:false, depth:false}) ?
>>
>> Well the idiomatic approach would be attributes on the element object
>> (and proxy, in the case of a worker-transfered canvas proxy), but if you
>> would like it to be on createElement() you'd have to ask the DOM guys.
>>
>>
>> > > I don't know why you have to specify them at all. :-)
>> >
>> > Because additional functionality that you do not need (such as alpha
>> > compositing, depth buffers, anti-aliasing, stenciling etc.) #1 occupy
>> > memory #2 slow things down.
>>
>> In the rest of the platform, we leave these kinds of things up to the UA
>> as a quality of implementation thing, typically. But I don't know enough
>> about them (and nobody is explaining them in enough detail) for me to know
>> if that makes sense here.
>>
>>
> These are not quality of implementation issues.
>
> depth buffers: take lots of memory. Are required for most 3D rendering,
> not required for most 2D rendering
> stencil buffers: take lots of memory, Are required for various effects and
> masking
> alpha: legacy code, OpenGL code, almost all assumes its alpha channel is
> ignored
> compositing: legacy code, OpenGL code, almost all assumes
> non-premultiplied alpha. Many game effects require non-premultiplied alpha
> antialiasing: this option is there to let you tell the system "don't
> antialias" as your image processing app might require that it has complete
> control of the output.
>
>
>
>>
>> > > Why would a canvas (not context, you've explained why a context may
>> > > wish to paint to different surfaces differently, e.g. to have an area
>> > > with AA and an area without or something) ever need to have its
>> > > settings changed?
>> >
>> > You're not drawing the same thing. You're re-using expensive resources
>> > (such as vertex buffers, textures etc.) or using computed resources
>> > (RTTs) to draw different aspects of your application onto different
>> > surfaces.
>>
>> So you have one rendering context with the vertex buffers, textures, etc,
>> and you draw them to multiple canvases.
>>
>> Why would you ever use different rendering contexts to draw to one canvas?
>>
>
> You probably would not use multiple contexts to draw to different canvases
> though conceptually there's nothing with it so why prevent it?
>
>
>> Or why would you change the settings on a single canvas between paints
>> from the same rendering context?
>>
>
> You wouldn't so why even suggest that you can by passing in the settings
> to setContext every time it's called?
>
>
>>
>> Or, for those proposing a DrawingBuffer model, why would you ever have
>> anything but a 1:1 mapping of DrawingBuffer to canvas?
>>
>
> Because using CSS you could have multiple views of the same drawingbuffer
> by associating a single drawingbuffer with multiple canvases.
>

PS: As I pointed out, this one is only a "nice to have" and it turns out
there's maybe already a different proposal for this particular usage case.
See
http://html5-demos.appspot.com/static/css/webkit-canvas.html (webkit/chrome
only)

I setup 3 divs to display 1 canvas. Top left is "zoom" view. Top right is
"radar or navigation" view. Background is "work" view. I didn't add
all the controls to make it work but it showing the use case mentioned
above.
http://jsfiddle.net/greggman/7SMem/ (webkit/chrome only)

That proposal seems like it's got serious issue with a separate
getCSSCanvasContext (why not just give the id of the canvas in CSS and be
done?)  but the point is, using 1 drawnigbuffer with multiple canvases is
not needed
if there is some css solution for this.

That still leaves the rest of these issues

*) Need a way create multiple drawingbuffers in a worker, each with their
own options

*) Need a way to set creation options on a canvas
    (which is effectively its internal drawingbuffer creation parameters)
see C++ class example

   *) consistent way, use the same method as workers. Make DrawingBuffer
with options. Then associate with a canvas.

   *) inconsistent way. Provide an new way to make Canvases with these
options and also a way to make Drawingbuffers in workers.

*) Need a way to draw to multiple drawingbuffers/canvases with 1 context.

   *) consistent way, use drawingBuffers in for both canvas2d and WebGL

   *) inconsistent way, use drawingBuffers in workers and canvases outside
of workers.







>
> But that's a "nice to have".
>
> The issue isn't the mapping of Drawingbuffer to canvas. The issues are
>
> 1) How to create something to draw to inside a worker not related to a
> canvas.
>
> 2) Where to put the creation parameters
>
> Both of those seem to lead to
>
>     Answer for #1)   Drawingbuffer (or whatever you want to call it)
>     Answer for #2)   parameters to the Drawingbuffer constructor.
>
> Then what follows after that are the repercussions. If you can create
> Drawingbuffers separately from Canvas then arguably the only difference
> between a Drawingbuffer and a Canvas internally references a Drawingbuffer
> as in a Canvas is
>
> class Canvas : public HTMLElement {
>    public:
>       DOMString toDataURL() { return m_drawingBuffer->toDataURL(); }
>       ...etc...
>    private:
>       DrawingBuffer* m_drawingBuffer;
> };
>
> Given that design other possibilities open up like 1 drawingbuffer,
> multiple canvases.
>
>
>
>
>
>
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20121219/cdc26921/attachment.html>


More information about the public_webgl mailing list