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

[Kenneth Russell]

On Tue, Mar 12, 2013 at 4:54 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> On Tue, Mar 12, 2013 at 4:16 PM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> On Tue, Mar 12, 2013 at 12:14 AM, Boris Zbarsky <bzbarsky at 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 at 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

putImageData measures the affected region of the scratch bitmap in CSS
pixels and putImageDataHD measures it in device pixels.
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-putimagedata