ruffle

ruffle copied to clipboard

This removes the dependency on core from every render backend crate, which speeds up compiling by allowing them to be done in parallel to core.

This is a step towards #6750 and allows for better code separation and organization.

For reviewing, take it commit by commit - I tried to keep them pretty self explanatory.

Long term I think it makes sense that types is actually core and what's currently core should be player - the glue between core, the AVMs, and stuff needed to actually play things. types suggests that it's purely plain old types and no functionality but that doesn't make sense for us here.

This removes the dependency on core from every render backend crate, which speeds up compiling by allowing them to be done in parallel to core.

Yay!

types suggests that it's purely plain old types and no functionality but that doesn't make sense for us here.

Perhaps backends is more fitting then at the moment?

More fitting for this PR yeah, but I hope to follow it up immediately with more stuff, ideally enough to theoretically have an AVM1 crate.

I ran a benchmark, master vs preinline vs inline And the results are...

• Overall compile time is the same, regardless of inline or not
• Inline has no impact on any compile times that I can see
• 2 seconds are removed from ruffle_core compile time, and ruffle_types takes 5 seconds to compile (in parallel)

After more things gets moved, especially avm, I'm sure we'll see a different story. But the fact that core goes down in compile time is great for development, that's the thing that changes the most

The biggest potential pitfall here is the Rust trait coherence rules. If we ever need a blanket impl for a trait in types, then the blanket impl will need to be defined in types as well, even if it needs to reference some type or global defined in core.

I don't anticipate this being much of a problem in practice, but it's something to keep in mind,

To be honest, looking at the latest commit

        // Chars get converted into flags.
        // This means "tbbtlbltblbrllrbltlrtbl" is valid, resulting in "TBLR".
        let mut align = StageAlign::default();
        for c in s.bytes().map(|c| c.to_ascii_uppercase()) {
            match c {
                b'T' => align.insert(StageAlign::TOP),
                b'B' => align.insert(StageAlign::BOTTOM),
                b'L' => align.insert(StageAlign::LEFT),
                b'R' => align.insert(StageAlign::RIGHT),
                _ => (),

This is starting to feel like core player "business logic" more than common type definitions.

That's why I said it's more appropriately named core and we should rename the current core to player - but that's far too big right now 😅

The ideal layout in my opinion is something like this:

• Core (currently proposed to be 'types'):
  • AVM1
  • AVM2
  • WebGL Render Backend
  • WGPU Render Backend
  • Canvas Render Backend
  • Player (currently 'core')
    • Desktop
    • Web
    • Exporter
    • Scanner

Extracting player from core is too big and invasive, as opposed to temporarily extracting core from player. If that makes sense?

I think I'm going to go back to the drawing board with this, after recent experiments I can't quits separate avm how I'd like so I'm unsure how to properly structure this for the immediate future.