- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 12 Mar 2013 17:02:59 -0700
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Tue, Mar 12, 2013 at 4:54 PM, Rik Cabanier <cabanier@gmail.com> wrote: > 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 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
Received on Wednesday, 13 March 2013 00:03:28 UTC