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

Boris Zbarsky bzbarsky at MIT.EDU
Mon Mar 11 22:14:46 PDT 2013

On 3/12/13 12:56 AM, Glenn Maynard wrote:
> (I suppose a simpler optimization is simply copy-on-access: make a copy of
> the backing store if the .data property of ImageData is accessed.

This may actually be a harder optimization to make in practice.

For example, Gecko+SpiderMonkey has the .data getter on ImageData 
objects annotated as being pure and returning a constant value.  This 
means that if you have code like this:

   img.data[0] = 1;
   img.data[1] = 2;

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

Based on some spot measurements, at first glance WebKit+V8 has somewhat 
similar behavior, however they get there (e.g. Gecko used to have a 
behavior somewhat like this by simply making ImageData be plain-vanilla 
JS objects with an own "data" property instead of WebIDL objects, and 
then the JIT can optimize gets using normal alias analysis techniques 
for slot gets).

But if .data can have side-effects the ability to do these sort of 
optimizations goes out the window and you get a much slower .data 
getter.  So you get a faster putImageData but the tradeoff is slower 
imagedata manipulation unless the script author performs the CSE and 
LICM optimizations by hand (which some do and some don't).

So there's no really good way to make this optimization without 
degrading performance of things people commonly do....


More information about the whatwg mailing list