[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)
On Tue, Oct 5, 2010 at 12:39 PM, Chris Marrin <email@example.com>
Your arguments are not that the two are orthogonal, but rather that you consider it more compelling to do in WebGL. In particular you can apply your argument 1b to WebGL as well. You can compute hit points with ray casting in WebGL without having the ability to read back the framebuffer. So I agree with Vlad, this issue can and should be dealt with at the Canvas level, not the WebGL level. If that means we are more constrained in this release, then I'm fine with that. We can always loosen the restrictions in later releases.
On Oct 5, 2010, at 11:31 AM, Brian Cornell wrote:
> I disagree for two reasons:
> 1. Fine grained origin tracking is much less useful for 2d canvas because:
> a) 2d canvas holds a lot less state than 3d canvas, making it a lot easier and less disruptive to simply draw to a second canvas without the other-origin data.
> c) 2d canvas already has some support for detecting what object a given pixel is part of.
> 2. Even if the canvas spec is changed to add support, the rules Gregg listed would still have to be in the WebGL spec just like section 4.2 currently clarifies how the origin-clean flag is affected by WebGL. The implementations and design are completely different and the only similarity is that they do the same basic thing. I don't see how the 2d canvas spec having or not having this functionality would change the WebGL spec with regard to this functionality.
> I'm not arguing that it shouldn't be added to the 2d canvas spec, just that they are orthogonal. I think it's far less useful in 2d canvas and will be met with more resistance because of this, but I have no complaint if people want to argue for it. I just don't think it should be ignored in the WebGL spec as something to deal with only after it gets added to the canvas spec.
My argument as to them being orthogonal is that the canvas spec having something similar would not affect WebGL. Imagine that Vlad's suggestion were implemented in the canvas spec today, would that somehow make it such that readPixels and tainted images could be used in the same WebGL context? I don't see how. So the WebGL spec would have to be changed in the exact same way whether or not it is adopted for 2d canvas.