- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 13 Aug 2013 18:57:33 +0000 (UTC)
- To: Kenneth Russell <kbr@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Mon, 12 Aug 2013, Kenneth Russell wrote: > > The use case is the passing of ImageData objects back and forth to > workers to fill and refill with data. > > An ImageData is essentially a wrapper for the underlying > Uint8ClampedArray, providing an associated width and height. However, > the only way to draw raw pixels into a Canvas is using an ImageData. > > Currently a Unit8ClampedArray can be constructed, but the only way to > create an ImageData is to ask a Canvas for one, and there's no way to > associate it with a pre-allocated Uint8ClampedArray. Why can't you just send an ImageData over? > This means that if you want to pass an ImageData to a worker for > filling, transferring the underlying Uint8ClampedArray, you need to be > very careful about bookkeeping, and to not lose the reference to the > ImageData object. Sure. Just send the ImageData over. That seems relatively straight-forward. What am I missing? > IMO there ought to be a factory method for ImageData taking a > Uint8ClampedArray, width, height, and possibly resolution (or a > dictionary?), which validates the width, height and resolution against > the size of the Uint8ClampedArray, and makes a new ImageData object. > This would ease management of ImageData instances. We could have a constructor for ImageData objects, sure. That would be relatively easy to add, if it's really needed. I don't understand why it's hard to keep track of ImageData objects, though. Can you elaborate? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 13 August 2013 18:57:57 UTC