Re: [whatwg] Canvas in workers

On Sun, Oct 20, 2013 at 11:47 PM, Robert O'Callahan
<robert@ocallahan.org>wrote:

> If you think that a single context outputting to multiple canvases
>> fundamentally won't work well with canvases of different sizes, then
>> forget
>> about the feature.
>>
>> When you attachToCanvas, you're attaching that canvas's rendering buffer,
>> not just its color buffer.  In WebGL terms, each canvas is a Framebuffer,
>> with all its associated Renderbuffers.  Attaching the context to a canvas
>> is like using bindFramebuffer to render to its backing store.
>>
>
> This is actually a disadvantage for attachToCanvas in some situations. If
> I just want to generate N different rendered images (of the same size)
> (e.g. http://www.turbosquid.com/Search/3D-Models/Vehicle/Car), the only
> thing I want N of is the final color buffer.
>

Note that it should be possible to reuse buffers as an optimization.  For
example, if you render to a canvas and commit(), then attach to a different
canvas of the same size, you could reuse the backbuffer you're already on
instead of creating a new one.  (For WebGL this requires a
preserveDrawingBuffer of false, which I think I specified as required in
the attachToCanvas proposal: attaching to a canvas always clears it.)  The
only thing you actually need to keep around in that case is the current
front color buffer that's being displayed.

That said, everyone prefers approaches that don't hinge on "this works fine
as long as you do this tricky optimization". If you have other use cases
for it, then having an API to retrieve an ImageBitmap is fine.  It just
doesn't seem like the right solution for rendering to multiple things in
the document.

-- 
Glenn Maynard

Received on Monday, 21 October 2013 23:45:53 UTC