Creating a new bug for this to capture the specific requirements we have for Shumway. # TL;DR, we need two things to be fast: - invoking methods on SOW-wrapped object - accessing values in SOW-wrapped typed arrays # Background: We want Shumway to be able to run multiple indepentent SWFs in one Shumway instance. For that to work, Shumway has to run in chrome and interact with multiple Canvas elements in different content windows. This currently works. (Well, not the multi-tenant capability, but that's because we also have work to do in the Shumway VM, itself.) However, it means that every interaction with the Canvas (and, far less critically, the content windows for user input) goes through wrappers. I did try to set things up such that the Shumway VM runs in the same principals as the content windows. For that, I created a sandbox with the same url as principals[1] in which the Shumway VM runs. The sandbox is set up to not require Xray-wrappers. IIUC, this should cause values from the window to be wrapped in SOWs instead of COWs, right? Assuming this is correct, here are our # Requirements: Shumway's interaction with the content window are two-fold: - receiving input - drawing onto the Canvas We don't expect to require too much read-back from the Canvas, as that is extremely costly with GPU-accellerated drawing, anyway. Receiving input shouldn't be a problem whatsoever, as it's a very low-bandwidth channel. That leaves writing to the canvas. Right now, we're doing that by invoking individual drawing methods on the Canvas's 2D rendering context. Potentially tens of thousands per frame. Most of the methods have only a few small arguments, mostly (short) strings and numbers. Some, however, take (potentially large) typed arrays. In short, we need two things to be fast: - invoking methods on SOW-wrapped object (the rendering context) - accessing values in SOW-wrapped typed arrays The first requirement we might be able to make far less important: we can probably install small scripts in the content windows that interpret typed arrays containing the drawing commands[2]. That only makes sense if the second requirement is less problematic than the first one, though. [1]: well, right now I give it the canvas-containing (unwrapped) window as the principals, but when going to multi-tenancy, this would probably be "resource://shumway/". [2]: Potentially, we could even create Canvas Path objects[3], which would then be drawn onto the Canvas by native code. They're not implemented yet and have a shitty constructor that'd force us to stringify everything, only to immediately parse that string again, though. [3]: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path

Oh, and all of this obviously doesn't even touch on what we're going to do in an e10s world. Mumble mumble transferrable objects something something. Maybe.

I think we should definitely do the typed array thing. As far as calling methods, we should think about what we can do... It might be "simplest" to do something like this: 1) Always invoke canvas methods via CanvasRenderingContext2D.prototype.something.call(args). 2) Teach ion to make this take the DOM fast-path when the thisobj passed in is a CCW for the right kind of DOM object. Not sure how to do this, given that TI doesn't track proxies very well. :( This would have the benefit of not needing any cross-compartment lookups to find the method and not needing to do anything interesting with the arguments, and basically inlining into the jitcode the unwrap before getting the C++ DOM object. The obvious drawback is that the code has to be written in an ass-backwards way. :( The alternative is to somehow make the foo.methodName lookups fast on a CCW for a DOM object and then make invoking those functions fast. I'm not quite sure what the right approach for that is.

So, another way to approach this might be the Canvas-access-from-workers thing. From bug 801176 comment 3: "What I proposed in bug 709490 is to provide a way to pass the context to the worker where only the context would be accessible rather then the canvas element. The canvas would also become inaccessible from the main thread to prevent headaches. It shouldn't make thing much worse." If we run Shumway in a shared worker, this would pretty much only leave the user input (and script interaction with the Flash element, but that's slow in Adobe's player, too). Maybe this approach could work in an e10s world, too?

Yeah, I think we should see how far we can get with JIT-ed typed arrays or shared workers, and come back to method invocation if we need to, since it's a much harder problem.

Doesn't need to block shipping Shumway.

This came up again in a conversation with Luke and bz. Shumway uses typed arrays to send serialized messages (and large buffers for images) between an iframe containing the VM and one containing the renderer. We recently discovered a huge performance fault caused by using an ArrayBuffer from the renderer iframe as the buffer of a typed array in the VM iframe. In theory, it should be possible to make this fast by using an unwrapped reference to the underlying buffer internally. The .buffer property would still return the original CCW. One concern is that the compartment containing the real ArrayBuffer could be destroyed through the hueyfix. In that case, we'd need to neuter the buffer in the other compartment. (I'm not sure what happens right now, actually.)