[whatwg] Canvas feedback

[Ian Hickson]

On Fri, 13 Mar 2009, Hans Schmucker wrote:
>
> This problem recently became apparent while trying to process a public 
> video on tinyvid.tv:
> 
> In article 4.8.11.3 "Security with canvas elements", the origin-clean 
> flag is only set depending on an element's origin. However there are 
> many scenarios where an image/video may actually be public and actively 
> allowing processing on other domains (as indicated by 
> Access-Control-Allow-Origin).
> 
> Is this an oversight or is there a specific reason why Access Control 
> for Cross-Site Requests should not work for Canvas?

I'm waiting for CORS to be a proven technology before using it widely in 
HTML. I think eventually it will be plugged into several features, 
including canvas and video, but for now it seems safer to wait and see.


On Sat, 14 Mar 2009, Hans Schmucker wrote:
>
> Question is: what would be the best way to fix it? Of course the spec 
> could be changed for video and image, but wouldn't it be simpler to 
> update the defintion of origins to include patterns that can represent 
> allow rules?

On Sat, 14 Mar 2009, Robert O'Callahan wrote:
> 
> I don't think changing the definition of origins is the right way to go.

I agree with Rob that we don't want to be changing the 'origin' concept. 
It's brittle enough as it is.


> It seems better to define a category of "public" resources, specify that 
> a resource served with "Access-Control-Allow-Origin: *" is "public", and 
> have <canvas> treat public resources specially.

I don't think we need "public" resources, just resources that have been 
allowed and resources that haven't (like with <video>). But this, IMHO, 
can wait for a while longer, until we have tested CORS with a few 
technologies and proved that it is a good technology.


On Sat, 14 Mar 2009, Biju wrote:
> 
> Just like canvas.getImageData() and canvas.putImageData()
>
> Why canvas.getImageHSLData() and canvas.putImageHSLData() API are 
> not provide? Is it something discussed and planned not have?

In practice user agents actually store image data as memory buffers of 
RGBA data, so handling RGBA data is (or at least can be) extremely 
efficient. HSLA data is not a native type, so it would be an inefficient 
type to provide native access to.

In practice, if you need to work in the HSLA space, then you should 
convert the data to HSLA and back manually, which would highlight the 
performance bottleneck implied in such an approach. Alternatively, convert 
whatever algorithms you are using to work in the RGBA space.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'