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

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

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 12 Mar 2013 18:16:21 -0500
Message-ID: <CABirCh8o4=_n3dr_9gW85cdt05t=bWysOFwvz0_SuV30z40r8Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: whatwg@lists.whatwg.org
On Tue, Mar 12, 2013 at 12:14 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> CSE can get rid of the redundant .data gets.  Similarly, .data gets can be
> loop-hoisted in many cases.
>

Doing COW based on page-faults is nicer anyway, but I don't know about the
data structures of JS engines to know whether this is feasible.  (For
example, if an object in JS is preceded by a header that gets written by
the engine now and then, it'll probably lie on the same page as the data,
which would trigger an expensive fault each time.)

I suppose padding the backing store so it doesn't share pages with anything
else might be reasonable here: up to about 8k of waste on a system with 4kb
pages.  The cost of marking the pages read-only would only have to be paid
when the copy-on-write action (eg. a call to putImageData) is actually
made.  Very small buffers could simply disable copy-on-write and always
perform a copy, where the waste for padding is more significant and the
benefits of avoiding a copy are smaller.

(For what it's worth, marking a 128 MB buffer read-only in Linux with
mprotect takes on the order of 3 microseconds on my typical desktop-class
system.  I don't know if Windows's VirtualProtect is slower.)

On Tue, Mar 12, 2013 at 4:04 PM, Rik Cabanier <cabanier@gmail.com> wrote:

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

The difference between getImageData(HD) and putImageData(HD) is in the
canvas operation, not the ImageData: it determines how pixels are scaled
when being read out of and written into the canvas backing store.  It
doesn't apply to this API; ImageData objects don't know anything beyond
their pixel data and dimensions.

(Code executing differently on high-DPI devices is a bridge we've already
crossed.  getImageData scales pixels down from the device's pixel ratio;
getImageDataHD doesn't, copying backing store pixels one to one.)

There is no real reason why you could use it in both HD and non-HD APIs.
>

Rather, there's no reason you couldn't.  You can definitely create an
ImageData with getImageData and then pass it to putImageDataHD (which would
cause the image to be scaled on devices with a pixel ratio other than 1, of
course).

-- 
Glenn Maynard
Received on Tuesday, 12 March 2013 23:16:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 12 March 2013 23:16:44 GMT