[whatwg] proposed canvas 2d API additions
hyatt at apple.com
Sat Apr 22 18:24:49 PDT 2006
This mail showed up pointlessly out of order. I see Ian already
On Apr 22, 2006, at 6:15 PM, David Hyatt wrote:
> The getPixels proposal seems broken to me in that it does not take
> into account high DPI, i.e., a situation where the canvas pixel
> space has been scaled and a more detailed image is possibly
> rendering within a region of the canvas. In this situation, a
> "canvas pixel" could actually be a bunch of device pixels that
> contain different color information.
> (hyatt at apple.com)
> On Apr 21, 2006, at 12:10 PM, Vladimir Vukicevic wrote:
>> Hi folks,
>> I'd like to suggest extending the HTML canvas 2d context with a few
>> additions. These are variations on some of the methods added to
>> Opera's "opera-2dgame" context. The methods are intended to give
>> content authors direct pixel access to the canvas, as well as provide
>> some basic point-in-path testing functionality.
>> float  getPixels (in integer x, in integer y, in integer width,
>> in integer height);
>> Returns an array of floats representing the color values in the
>> of pixels in the canvas whose upper left corner is at (x,y) and which
>> extends for width,height pixels. These coordinates are in canvas
>> pixel space (that is, the same space that the canvas width and height
>> attributes are specified in). The color values for each pixel are
>> returned as 4 floats, each in the range of 0.0 to 1.0, in R,G,B,A
>> order. That is, given the paramters (0,0,2,2), the returned array
>> will be [R00 G00 B00 A00 R10 G10 B10 A10 R01 G01 B01 A01 R11 B11 G11
>> Note: we could return the pixels as integers in the range of 0..255,
>> as 8-bit color is most likely what canvases will be dealing with.
>> However, using floats allow us to easily extend into a 16-bit
>> colorspace without any API changes. In addition, any computation
>> using these pixels is often done in normalized colors, so the
>> by 255 would need to happen anyway.
>> void putPixels (in float  pixels, in integer x, in integer
>> y, in
>> integer width, in integer height);
>> Does the opposite of getPixels; the given array must be exactly width
>> * height * 4 elements in length. The values are to be clamped to
>> boolean pointInPathFill(in float x, in float y);
>> pointInPathFill returns true if the given point would be inside the
>> region filled by the current path, and false otherwise. The x,y
>> coordinates are in the current space of the canvas; that is, they are
>> transformed by the CTM and do not necessarily map directly to pixels.
>> I'd suggest that these three functions be added directly to the "2d"
>> context; content authors can test for their presence by checking the
>> function is not null on the 2d context object. We might want a more
>> comprehensive way of letting authors test whether particular features
>> are supported, e.g. "shadows", "pixel-access", etc, but maybe it's
>> How's this sound?
>> - Vlad
More information about the whatwg