In bug 433004, there is a patch that implements a real CanvasPixelArray object in the DOM for canvas image data. However, that causes serious performance issues, so createImageData was initially implemented to just return a JS object much like the previous impl. To do this 100% correctly requires: 1) dense JS arrays that xpconnect can talk to; 2) fast array access with clamping.
The wording in comment #0 seems strange to me. I would say that this requires a fast, direct way for C++ objects to implement the WebIDL IndexGetter and IndexSetter attributes. Once that functionality exists, it seems like this will not be terribly hard -- maybe even a student project. Sorry if I'm wrong about this.
Doesn't JSAPI allow this already?
Re comment #2: not really. Dense arrays are not the model to copy; they implement JSObjectOps, which is not public API; they get help from the interpreter and JIT; and they *still* regressed some JSAPI functionality (dense array thread safety). Plus, IIRC, it was really hard. The String class does its str[int] thing using straight JSAPI, but it's a resolve hook and a JSScopeProperty for each character accessed. It's inefficient. You can almost implement this using JSClass.getProperty, but the semantics aren't right. The properties don't really exist in that case; getProperty is sort of a catchall. So the prototype chain gets searched when you try to access a numeric property.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 534467
You need to log in before you can comment on or make changes to this bug.