- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 12 Mar 2013 14:04:52 -0700
- To: Kenneth Russell <kbr@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>
On Tue, Mar 12, 2013 at 11:40 AM, Kenneth Russell <kbr@google.com> wrote: > On Tue, Mar 12, 2013 at 11:15 AM, Rik Cabanier <cabanier@gmail.com> wrote: > > sounds good! > > I think this is a convenient and useful addition. > > Great. > > > do you want to keep doubles to define the dimensions instead of > integers? If > > so, the size should probably 4 * ceil(sw) * ceil(sh) > > I would prefer to use integers, and only used doubles to be consistent > with the other APIs like getImageData and createImageData. In this > case it would make more sense to use integers, since the width and > height are simply being used to interpret preexisting data in the > Uint8ClampedArray. The current canvas spec doesn't specifically state what happens with partial pixels. What happens today? (Also is there a definition somewhere that states when a pixel is considered filled?) > I don't think it is necessary to provide a createImageDataHD in this > interface. The caller will know the devicePixelRatio and determine > whether to generate high-DPI data. That probably won't work since it results in code that executes differently on devices that are HD. > > > On Tue, Mar 12, 2013 at 10:50 AM, Kenneth Russell <kbr@google.com> > wrote: > >> > >> It should simply reference the Uint8ClampedArray, not copy it or do > >> anything else esoteric. The only way to display an ImageData in the 2D > >> canvas context is via the putImageData API. I am not proposing > >> changing those semantics. > >> > >> -Ken > >> > >> > >> > >> On Mon, Mar 11, 2013 at 5:00 PM, Rik Cabanier <cabanier@gmail.com> > wrote: > >> > Do you expect that createImageData creates an internal copy of the > >> > Uint8ClampedArray object or is it live? > >> > > >> > > >> > On Mon, Mar 11, 2013 at 4:28 PM, Kenneth Russell <kbr@google.com> > wrote: > >> >> > >> >> It would be useful to be able to create an ImageData [1] object with > >> >> preexisting data. The main use case is to display arbitrary data in > >> >> the 2D canvas context with no data copies. > >> >> > >> >> Proposed IDL: > >> >> > >> >> [NoInterfaceObject] > >> >> interface ImageDataFactories { > >> >> ImageData createImageData(Uint8ClampedArray data, double sw, double > >> >> sh); > >> >> }; > >> >> Window implements ImageDataFactories; > >> >> WorkerGlobalScope implements ImageDataFactories; > >> >> > >> >> createImageData would throw an exception if the length of the > >> >> Uint8ClampedArray was not equal to 4 * floor(sw) * floor(sh), or at > >> >> least, if the length of the array was less than this value. (Similar > >> >> wording would be used to that of CanvasRenderingContext2D's > >> >> createImageData.) > >> >> > >> >> I don't think it is necessary to provide a createImageDataHD in this > >> >> interface. The caller will know the devicePixelRatio and determine > >> >> whether to generate high-DPI data. > >> >> > >> >> [1] > >> >> > >> >> > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata > >> >> > >> >> Comments? > >> >> > >> >> Thanks, > >> >> > >> >> -Ken > >> > > >> > > > > > >
Received on Tuesday, 12 March 2013 21:05:21 UTC