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

On Tue, Mar 12, 2013 at 4:16 PM, Glenn Maynard <glenn@zewt.org> wrote:

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


It feels like something is missing. How does putImageDataHD know that the
bitmap should be scaled? Width and height refer to the pixel dimensions and
not the 'px' unit

Received on Tuesday, 12 March 2013 23:54:44 UTC