implement real CanvasPixelArray object

RESOLVED DUPLICATE of bug 534467

Status

()

RESOLVED DUPLICATE of bug 534467
10 years ago
9 years ago

People

(Reporter: vlad, Unassigned)

Tracking

({student-project})

Trunk
x86
All
student-project
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Comment 2

10 years ago
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.