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

Re: [Public WebGL] WEBGL_dynamic_texture redux



Hi Ken,

Comments inline.

On Wed, Oct 31, 2012 at 3:00 PM, Kenneth Russell <kbr@google.com> wrote:
>
> Hi Mark,
>
> Thanks for putting together this sample. A few thoughts.
>
>   - Keeping the video stream separate from the video element seems cleaner. I think we should avoid APIs which require mutating HTML elements, and in particular, adding new properties.

What about classifications? Can you specify HTML elements implementing
an empty interface without members? It seems to me that
HTMLVideoElement, HTMLImageElement, HTMLCanvasElement, and
WebGLStreamObject (?) are all video stream providers.

>   - When thinking about creating streams for arbitrary canvases, not just video elements, how will the producerFrame be handled? Today, when JavaScript code modifies a 2D canvas, the results are made available (a) when the web page is composited, (b) when a readback API like toDataURL / getImageData is called, or (c) when WebGL uploads the canvas via texImage2D / texSubImage2D. It's a "pull" model. When a stream is connected, and the canvas is modified in the current JavaScript callback, should acquireImage() cause a flush of the upstream canvas and an update of the producerFrame at the same time? I think it should. Is there any issue with spec'ing this behavior?

How does requestAnimationFrame pull? How does the upstream canvas
discover its consumer latency? Is there a way to take advantage of the
render pipeline to ensure that the requisite frame has flushed before
it is pulled? Do stream objects maintain framebuffers for sinks with
varying latencies or does everything have to be rendered twice?

Waiting for a flush doesn't sound nice but perhaps I misunderstand.

>   - You point out that cpc won't update when the tab is backgrounded, but there are other issues: (a) the WebGL app might decide to not produce new frames sometimes (if the scene isn't updating); (b) msc won't update if the browser decides not to repaint because the page didn't update at all; (c) for backgrounded tabs it's unlikely that msc will update, and requestAnimationFrame will stop, but setTimeout based timers will still probably fire. Are there issues with any of these behaviors? I think probably not; applications will use the page visibility API to know when they've been backgrounded and suspend any measurements of frame rate.

Why won't msc update? No background audio/video playing? Is this the
present behavior? Flash A/V doesn't do this, afaik, and people rely on
this behavior for auditorily monitoring videos.

David

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------