Re: Canvas 2D API specification update

On Thu, Oct 22, 2009 at 4:40 AM, Philip Taylor <pjt47@cam.ac.uk> wrote:
> 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.
>

Interesting. Good point, good feedback.

Canvas would not be the first item split from HTML5, that required
both clean up and special attention to ensure that the two specs do
not become out of sync. As you say, not an insurmountable obstacle.


>> 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.
>

But if we continue to include everything in the HTML5 spec that we're
concerned will fall between the cracks, Michael Smith will continue
having to override file limits in order to maintain the existing HTML5
document.

Separate specifications does not mean separate groups. One can
participate in more than one group, and one can following more than
one working group. In addition, people can also file bugs, and raise
issues and concerns.


> --
> Philip Taylor
> pjt47@cam.ac.uk
>
>

Shelley

Received on Thursday, 22 October 2009 14:18:50 UTC