Skip to content

chore: Update lyon and update image tests based on the changes#22961

Open
danielhjacobs wants to merge 1 commit intoruffle-rs:masterfrom
danielhjacobs:lyon-update
Open

chore: Update lyon and update image tests based on the changes#22961
danielhjacobs wants to merge 1 commit intoruffle-rs:masterfrom
danielhjacobs:lyon-update

Conversation

@danielhjacobs
Copy link
Contributor

No description provided.

@danielhjacobs danielhjacobs added A-deps Area: Dependencies T-chore Type: Chore (like updating a dependency, it's gotta be done) labels Feb 6, 2026
@torokati44
Copy link
Member

In case you did a "global" cargo update - that won't work.

@danielhjacobs danielhjacobs force-pushed the lyon-update branch 4 times, most recently from c586648 to c54bf3b Compare February 6, 2026 17:55
@danielhjacobs danielhjacobs marked this pull request as ready for review February 6, 2026 17:55
@danielhjacobs danielhjacobs changed the title chore: Update lyon chore: Update lyon and update image tests based on the changes Feb 6, 2026
@torokati44
Copy link
Member

Are the new images from FP or from Ruffle?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

c.f.: github.com/torokati44/ruffle/commit/33840417a40c6f249ffc4f716980cc71dea31bf4

How come euclid and libm needed to be bumped here, but not there?
And why leave lyon_geom version unchanged in Cargo.toml if it was bumped here?

Just curious, not saying either is better or worse.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did cargo install cargo-edit, then cargo upgrade -i -p lyon (https://stackoverflow.com/a/78514408/30680220), and it did this.

Before doing that, I tried just doing cargo update lyon, which didn't include these changes and committed that, but that told me "cannot update the lock file /home/runner/work/ruffle/ruffle/Cargo.lock because --locked was passed to prevent this" (https://github.com/ruffle-rs/ruffle/actions/runs/21757252217/job/62770890789)

@danielhjacobs
Copy link
Contributor Author

From Ruffle, but here's a different question: were the old images from Flash Player either?

https://github.com/ruffle-rs/ruffle/commits/master/tests/tests/swfs/avm2/bitmapdata_drawwithquality/output.expected.png

@torokati44
Copy link
Member

I don't think so, that's why they need to be updated now (and possibly again in the future).

@danielhjacobs
Copy link
Contributor Author

The proper thing to do would be check each of them to see if they match Flash Player more accurately now than they did before, but:

  1. I don't have easy access to Flash Player
  2. I have trouble seeing the exact differences even now (I think it's to do with the exact pixels of the borders of the shapes)

@danielhjacobs
Copy link
Contributor Author

It can be rather difficult when the shape has a mild difference like this
Screenshot From 2026-02-06 14-59-19

@torokati44
Copy link
Member

Sure, it's understandable. It was Ruffle images all along exactly because capturing FP is non-trivial.

@danielhjacobs
Copy link
Contributor Author

kjarosh suggested on Discord we should take the output from Flash. It will take me some time to update this PR doing that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-deps Area: Dependencies T-chore Type: Chore (like updating a dependency, it's gotta be done)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants