- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 9 Aug 2013 21:34:35 +0000 (UTC)
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>
On Fri, 9 Aug 2013, Rik Cabanier wrote: > On Fri, Aug 9, 2013 at 1:32 PM, Ian Hickson <ian@hixie.ch> wrote: > > On Mon, 11 Mar 2013, Kenneth Russell 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. > > > > Doesn't ImageBitmap support this already? I'm not sure I understand > > the use case here. Where are you getting the image data from, that > > it's already in raw RGBA form rather than compressed e.g. as a PNG? > > (Presumably this isn't coming over the network, since I would imagine > > the time to compress and decompress an image is far smaller than the > > time to send uncompressed data. But maybe I'm wrong about that.) > > From re-reading the thread, it seems that this data comes from the > server (or a web worker?) as uncompressed data. The http protocol likely > did compression on the packets so the size difference is probably not > that great. > > I think the use-case is to avoid having to copy over the data pixel by > pixel from the arraybuffer. Could you elaborate on the use case? I'm happy to believe that there are times that a server or worker is generating lots of pixel data, but having never run into such a case myself, I would very much like to understand it better. It may be that there are better solutions to the real underlying problem. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 9 August 2013 21:34:58 UTC