On Tue, Mar 12, 2013 at 4:16 PM, Glenn Maynard <gl...@zewt.org> wrote:
> On Tue, Mar 12, 2013 at 12:14 AM, Boris Zbarsky <bzbar...@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 <caban...@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