Also... should the RGBA data be returned with premultiplied alpha or not? Premultiplied tends to be better for the math, non-premultiplied tends to be easier to understand. (That is, 50% opaque green is (0,255,0,128) if non-premultiplied, or (0,128,0,128) if premultiplied.)
- Vlad On 5/4/06, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote:
On 4/28/06, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote: > interface ImageData { > readonly attribute string format; /* only "rgba" is valid for now */ > readonly attribute long int width; > readonly attribute long int height; > readonly attribute Array data; > } Actually, let's step back a second; this may be massive overengineering. What if we simply had: readonly attribute float deviceScaling; on the 2D context, which would give the scaling factor between canvas-space pixels (that is, the space that the <canvas> width/height attributes are in) and device-space pixels (the pixels of the actual backing store). So if <canvas width="200" height="200"/> was represented with a 300x300 backing store, deviceScaling would be 1.5; if 400x400, it would be 2.0. (If necessary, we can have deviceScalingX, deviceScalingY.) Then getPixels is defined to take parameters in canvas pixel space, and returns the ARGB array in device space; if you ask for a 50x50 region, you'll get back 100x100x4 samples, with a deviceScaling of 2.0. putPixels would take coordinates in canvas pixel space again, but would take the appropriate device-pixel-sized ARGB array. This becomes tricky with non-integer deviceScaling; that is, if a 2x2 region becomes a 3x3 region with a deviceScaling of 1.5, what do you return when you're asked for x=1 y=1 w=1 h=1? I'd say that you end up resampling and shifting over your 3x3 device space backing store by .5 pixels so that the region would start on a device pixel boundary. This would obviously not be a clean round-trip, but the spec can inform authors how to ensure a clean round trip (only request regions where your x/y * deviceScaling are integers). This removes the need for a separate ImageData object and all the extra gunk necessary there, but still maintains full resolution independence. Any thoughts on this? - Vlad