W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2015

Re: Canvas capture update

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 12 Aug 2015 15:11:19 +0200
Message-ID: <55CB45F7.4090402@alvestrand.no>
To: public-media-capture@w3.org
Since I'm sure others are as ignorant as I am about how Canvas actually
works:

When is a canvas painted?
Is this a display-triggered event or a Javascript-triggered event?

If the former, I have worries about what happens with non-rendered canvases.
If the latter, I have a host of different questions.

Den 11. aug. 2015 18:50, skrev Martin Thomson:
> As some of you might be aware, Firefox has an implementation of media
> capture from <video> and <audio> tags.  We also have an implementation
> of capture from <canvas>, which you can test in nightly builds by
> enabling "canvas.capturestream.enabled" in about:config.
> 
> Part of the reason that this is behind a pref is that we discovered
> that capturing from webGL canvas had some challenges, particularly
> when preserveDrawingBuffer is true.  Based on feedback from that
> effort, and thanks to Andreas, I've created a pull request that
> specifies when capture happens more precisely.
> 
> https://github.com/w3c/mediacapture-fromelement/pull/11
> 
> The idea here is that you only capture frames when the canvas is
> painted.  The frame rate setting becomes a guide; the exact time of
> capture will usually be slightly after the frame rate setting hits.
> 
> As a result, or at least once we have this correctly implemented [1],
> it should be possible to capture media from a canvas with close to
> zero performance impact.  Of course, doing something with the captured
> stream could have performance consequences.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1161913
> 
Received on Wednesday, 12 August 2015 13:11:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:33 UTC