W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: Canvas 2D API specification update

From: Philip Taylor <pjt47@cam.ac.uk>
Date: Thu, 22 Oct 2009 10:40:28 +0100
Message-ID: <4AE0288C.2050309@cam.ac.uk>
To: Julian Reschke <julian.reschke@gmx.de>
CC: "public-html@w3.org" <public-html@w3.org>, Eliot Graff <eliotgra@microsoft.com>, Adrian Bateman <adrianba@microsoft.com>, Frank Olivier <franko@microsoft.com>
Julian Reschke wrote:
> I admit that I don't know what the "structured clone feature" is, but if 
> it's orthogonal to Canvas, then having its specifiction rely on Canvas 
> is a problem -- if even if Canvas stays where it is.

http://whatwg.org/html5#safe-passing-of-structured-data

It's used for cloning data structures to send through postMessage(), to 
other documents or to worker threads. Originally I think postMessage() 
only supported strings, but it was extended to allow simple and 
efficient passing of complex data structures. Cloning is necessary to 
avoid security and synchronisation issues.

One use for workers is concurrent background computation. The canvas API 
has getImageData()/putImageData() to let you extract parts of the canvas 
bitmap and perform computations on the pixels. It's therefore a useful 
feature to be able to pass ImageData objects efficiently to workers (and 
back again) using postMessage. Since ImageData is a special object type 
(normal JS arrays would be too inefficient at storing bitmap data), the 
structured clone algorithm has to handle it specially.

If the canvas ImageData structure was defined in a separate spec, I'd 
expect HTML5 to ignore ImageData and the new spec to override HTML5's 
definition of 'structured clone' (as allowed by 
http://whatwg.org/html5#other-applicable-specifications). That avoids 
bi-directional references, and doesn't seem like an obvious nightmare to 
me, though it would introduce a new risk of the specs getting out of sync.

> This is *exactly* the problem one would expect when things are defined 
> in a monolithic way.

On the other hand, it's exactly the useful feature one would expect to 
fall between the cracks and not get specified or supported at all, when 
things are defined in separate specs by separate groups.

-- 
Philip Taylor
pjt47@cam.ac.uk
Received on Thursday, 22 October 2009 09:40:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC