W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data

From: Kenneth Russell <kbr@google.com>
Date: Mon, 12 Aug 2013 18:25:24 -0700
Message-ID: <CAMYvS2cMQz0CjGqt5kJALTfvhEsg87mOzTsqT5bRO8dLuzthgQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: WHAT Working Group <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Fri, Aug 9, 2013 at 2:34 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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.

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. 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.

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.

-Ken
Received on Tuesday, 13 August 2013 01:25:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC