Closed Bug 453355 Opened 16 years ago Closed 14 years ago

implement real CanvasPixelArray object

Categories

(Core :: Graphics: Canvas2D, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 534467

People

(Reporter: vlad, Unassigned)

References

Details

(Keywords: student-project)

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.
Keywords: student-project
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.
Depends on: 497795
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.