W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

Re: Image Capture Proposal, fourth version

From: Johannes Odland <johannes.odland@gmail.com>
Date: Tue, 30 Apr 2013 17:11:58 +0200
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-Id: <5F0C5C7E-ECC3-4618-87E7-01BC1CDA6097@gmail.com>
To: "Mandyam, Giridhar" <mandyam@quicinc.com>

Thanks for the update. 

I have some notes I made while reading the new version:


1. Reference to frameGrabber
There is still a reference to the frameGrabber method in there in a note: 
{Note: Unlike frameGrabber(), getFrame() returns data only once upon being invoked.}

2. Examples
In the examples it is no longer necessary to create a canvas to instantiate a CanvasRenderingContext2D. 
The constructor for CanvasRenderingContext2D is in the living standard now:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext

var canvas = document.createElement('canvas');
    ctx = canvas.getContext("2d");
can be
var ctx = new CanvasRenderingContext2D();

(We should avoid cluttering the global scope with variables and define the variables locally using var unless )

I know it's not in the CR right now, so maybe this still have to wait.

3. Futures
To me futures seems like a perfect fit for the grabFrame method. 
With futures one could not only chain callbacks, but also get proper error handling:

imageCapture.getFrame()
	.then(processFrame) 
	.then(lookUpBarCode)
	.then(displayResult)
	.catch(displayError);

I hope Futures will still be considered for the ImageCapture API.


-Johannes Odland



On Apr 26, 2013, at 6:49 PM, "Mandyam, Giridhar" <mandyam@quicinc.com> wrote:

> <Mediastream Image Capture.htm>
Received on Tuesday, 30 April 2013 15:12:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC