Back when Shumway was under development I remember using the first big Homestuck walkaround flash (https://www.homestuck.com/story/1358?fl=1) to put it through its paces and found it to be unbearably slow to the point of unplayability. If Ruffle is capable of running those at any reasonable speed then that would demonstrate real progress over what Shumway achieved.
Looking at the code, Shumway seems amazingly complete vs. Ruffle. Ruffle has only a tiny skeleton of AS3 support (only the VM opcodes and some of the MovieClip class), while Shumway seems to implement a huge chunk of the library classes.
Maybe using wasm Rust with WebGPU acceleration will make it faster than Shumway. Remarkable to me how much effort must have been put into Shumway, though..
DisplayObjectContainer support just landed a few days ago, but yes, our AS3 support is basically nothing right now. Most of our effort has gone into finding and implementing the bottomless pit of strangeness that is AVM1 and it's execution model. Adding AS3 support also means making sure we can leverage the same object hierarchy without breaking any of those fixes. For example, after figuring out how DisplayObjectContainer IDs and timeline depths interact, Toad06 and I went through several rounds of regression testing with AVM1 content because of how foundational the changes were.
Shumway used to be a Mozilla project with corporate backing; that would explain why their implementation was so complete. (Ruffle is all people working spare-time currently) The performance ceiling with Rust is way higher than JavaScript, but we're nowhere near that yet, much yet at the point where we'd have to start writing JIT compilers for AS2 or AS3. We are using GPUs to render polygonalized shapes where available, though that has some accuracy issues with stroke scaling. Ideally, we'd like to have some kind of low-level Flash-like vector drawing implementation, but that would be a significant performance loss unless we could either parallelize it or somehow convince a GPU to do it.
Furthermore, a lot of that is going to have to come after all the compatibility and implementation work we still need to do. Off the top of my head...
1. Core AS3 display object support - I'm working on this with somewhat-slow progress
2. Core AS3 data types (String, Number, int, uint, Vector.<$>, Point, Transform, JSON, etc) - I'll do this as-needed for other AS3 work or specific games that depend on these methods
3. Video decoding - I have an h263 decoder written but still need to tie it into the stage, and it'll probably be super-inefficient on web unless I port decoding over to GPU shaders
4. Remaining AS2 classes - Someone PR'd BitmapData support but it's incomplete. There's also some security-related and custom socket classes which expose the movie's origin, which is validated by some domain locks.
5. XML - I have a custom DOM and AS2 integration for it, but we need to write our own custom parser and also tie it into both legacy XML and E4X XML on AS3
I'm about 90% sure this is possible using techniques broadly similar to piet-gpu. The problem is a lot less constrained if you have access to compute shaders (ie WebGPU), otherwise it looks a lot like RAVG (Nehab and Hoppe) and you have kinda nasty branching and memory access patterns in the fragment shader, plus still having to do coarse rasterization on CPU.
One of the operational challenges here is that the renderer would likely be a one-off, as the requirements are just so different than most other clients of a 2D rendering engine.
There's been a bit of discussion on #gpu on xi.zulipchat.com. I consider this an interesting problem but can't really justify spending time on Flash-specific features myself.
Shumway didn’t need to implement a full ActionScript virtual machine because it converted ActionScript bytecode to JavaScript and eval’ing it at runtime, leveraging both the JavaScript engine’s runtime and JIT.
I think ActionScript has a lot of APIs not available in JavaScript that stop needed to be hand implemented. That said, Shumway was able to auto-generate API stubs at compile time from “player debugger” symbol files that Adobe distributes for ActionScript debuggers. :)
