Why is getImageData not allowed?

[cabanier]

it seems that it should be OK to call getImageData, as long as you don't actually try to reach the pixels.
Moreover, maybe ALL access to image pixels should be disallowed (even from the regular images) so you can avoid CORS.

[tabatkins]

What's the purpose of calling getImageData if you don't touch the pixels?

The reason it's disallowed is because we want to allow implementation schemes that store the commands directly in the rendering abstraction used by the rest of the page, such as DisplayLists in Chrome, rather than requiring them to raster and take additional memory.

[cabanier]

With GetImageData you would be able to take snapshots of the canvas pixels and then draw them multiple times, or apply group opacity/blending or create a pattern.
As long as you don't actually read the pixel data, this can be done with a display list since they're just commands that can be replayed.

Also, unless you want to globalCompositeOperation to read from behind the element, the rendering should be done to an intermediate raster.

[bfgeek]

Right, I think this is the core of the issue, that by removing getImageData we remove the ability to easily do tiling/compositeOperation/etc.

I think a better solution to this would be to make a new API explicitly for this, I.e. get a transparent handle for a region of the canvas, then able to draw it somewhere else. Or have the ability to create a sub-canvas, which you can then tile onto the main canvas.

Would have to think about if there are any other implications by doing this however.

I thinking about connection with main js context, and dynamic receiving from external canvas images data.

/* the sample of external data receiver */
var images = {};
receive("image", function(res) {
  images[res.to] = createRGBAImage(res.rawData); //the same as create canvas in plain js
  sendRequest("wait");
}); 
sendRequest("hello");

... 
/* on painting */
ctx.drawImage(images[...], 0, 0);

About getImageData is disallowed, I partially agree.

[cabanier]

Yes, it would be good to have an api that can create a blank canvas. It could negate the need to have a getimagedata API since you could then draw parts of the temporary canvas.

[bfgeek]

@cabanier I've tried to capture this discussion in #34 . Does that issue capture most of your use-cases/problems?

@acterhd In the future, please open additional issues for specific questions instead of adding to an existing issue. This allows people in the future to find the answer to the question easier via. searching, etc.

External data will be exposed through custom properties. For example:

// main.js
document.registerProperty({
  name: '--my-image',
  syntax: '<image>'
});

/* style.css */
#element { --my-image: url(#image-uri); }

// paint.js
registerPaint('foo', class {
  static inputProperties = ['--my-image'];
  paint(ctx, geom, styleMap) {
    var imgHandle = styleMap.get('--my-image');
    ctx.drawImage(imgHandle.dataHandle); // Transparent handle to image data.
  }
});

Look to my questions... I opened issue.
I think I all understand, you want unify CSS4 and Houdini...? I have few arguments about...

[cabanier]

@bfgeek yes, it think that captures it.
Still unfortunate that getImageData is disallowed, but if it makes the implementation easier and we can get rid of CORS, it's acceptable.

[bfgeek]

@cabanier Thanks, I'm closing this for now; at the F2F there isn't much appetite for getImageData, a constructor for PaintRenderingContext2D moved to a next level for now.