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

Re: [Public WebGL] using the same context with multiple canvases






On Wed, Dec 19, 2012 at 6:31 AM, Ian Hickson <ian@hixie.ch> wrote:
On Tue, 18 Dec 2012, Florian Bösch wrote:
> On Tue, Dec 18, 2012 at 8:13 PM, Ian Hickson <ian@hixie.ch> 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.

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.   `._.-(,_..'--(,_..'`-.;.'