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

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

Hi Gregg,

A DrawingBuffer is created by constructor as in

   var db = new DrawingBuffer(context, ....

This calling style has one negative side, what if there is no more memory or parameters are incorrect and DrawingBuffer can not be created ?
Why not simply add a createDrawingBuffer to the WebGLRenderingContext  IDl ?

interface WebGLRenderingContext {
    DrawingBuffer createDrawingBuffer( ... )

The same style as createShader, createProgram, e.t.c were done ? 



On 2/8/2013 2:55 AM, Gregg Tavares wrote:
So I posted a new proposal for canvas in workers and using the same context with multiple canvases to the WhatWG wiki

This comes from discussions at the WebGL Working Group Face 2 Face meeting and from input from the Google Maps team. I mention that not to give it any authority, only rather not to take credit for a group effort.

I hope we're getting close though :-)

On Thu, Jan 31, 2013 at 8:05 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Thu, Jan 31, 2013 at 3:09 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
Effectively, we would create a DrawingBuffer object either from a Canvas or via direct use of the constructor. If not created from a Canvas, you will only be able to use it for offscreen rendering. This object is Transferable, and contains the back buffer that WebGL will render into. It also contains a front buffer that will be Presented to the compositor. (Well, at least for the DrawingBuffers created from Canvases) DrawingBuffer will have a commit() function that swaps the back buffer to the front buffer.

Context creation attributes like `alpha` and `preserveDrawingBuffer` would be ideally be attached to the DrawingBuffers, not WebGL contexts.
I assume this means there is going to be a function like canvas.createDrawingBuffer(attribs)?

One major point not yet resolved is how to better synchronize Commits such that two or more Canvases can assure that each of their new frames is composited at the same time, so composite renderings are smooth and don't fall out of sync. This is workable currently by using a compositing RenderingContext, and doing the composition manually, but we may be able to come up with a way to assure rendered frames from different Canvases are composited together consistently.
I'm not sure it's relevant but I have one odd use-case I stumbled into. In an application I'm writing I offer a "pop out" functionality that creates a popup window, the canvas is removed from the main page and attached to that popups body. This works fine, except that requestAnimationFrame has to be switched over to be called from that popups document (otherwise there is compositional flickering) as the two windows are not drawing in sync of course. At present this is the only way to do it (detach, attach to new documents body) since the canvas is unchangably bound to that context. With the ability to present a drawing buffer to a canvas, the method could be slightly improved by not sticking foreign elements into a popups DOM (I somehow feel that would be cleaner). However it'll probably still present somewhat of a syncing challenge.