Shipping the png crate in Chromium

[anforowicz]

Hello!

I really appreciate all the work that has been put into the png crate (and fdeflate crate as well as the Rust toolchain and other Rust crates). As a way of saying "thank you", let me share the status (and excitement) of what is going on with shipping the png crate in Chromium.

We started Chrome Canary experiments in the 2nd half of December 2024. I initially planned to also start Dev experiments and try shipping in M133, but it took me longer than expected to fully hook up the encoder. I hope to start Dev experiments in early January and try shipping in M134.

Below are some additional details in the form of questions and answers. Let me know if you have any other questions.

---

Q: What Chrome versions participate in the experiments?

• Chrome 133.0.6891.0 is the first version with Rust PNG built into the binary. Rust PNG is disabled by default in this version, but can be force-enabled using chrome://flags/#rusty-png.
• Chrome 133.0.6892.0 is the minimum version for participating in the current Canary 50%-50% experiments.

We don’t have enough experimental data to ship in M133, but depending on the experiment results on earlier channels, we plan to expand to M134 Dev, Beta, and Stable during Q1 2025. For a tentative Chromium release schedule please see https://chromiumdash.appspot.com/schedule.

Q: How can I tell which experiment group I am in?

To find out which experiment group you are in, go to chrome://version and search for “977e3a5f” in the list of “Active Variations”:

• Control groups:
  • 977e3a5f-89078435 maps to RustyPng-Control_20241212
• Enabled groups:
  • 977e3a5f-2a45d995 maps to RustyPng-Enabled_20241212

Note that getting assigned to one of the experiment groups may depend on getting a new field trials “seed” and therefore may require rebooting a browser. Also note that your local ChromeVariations enterprise policy may limit which field trials you may participate in.

Q: Can I switch to a different experiment group?

You can't pick which experiment group you will be assigned to. Experiment group assignment happens randomly, and is “sticky” / “permanent” for the given Chrome client.

If you want to force Rust png on or off (e.g. to triage if the field trial may be responsible for a bug), then navigate to chrome://flags/#rusty-png and force the flag to be enabled or disabled. Note that this will exclude you from the A/B comparisons (i.e. you will be assigned to “ForcedOn_…” or “ForcedOff_…” group, rather than to the control or the experiment group).

Q: What versions of the libraries are covered?

• Control group: libpng/zlib-based decoders and encoders that normally ship in Chromium
  • blink::PNGImageDecoder
  • SkPngDecoder (used mostly through //ui/gfx/codec/png_codec.h API)
  • SkPngEncoder (used mostly through //ui/gfx/codec/png_codec.h API)
• Experiment group: Chromium/Skia’s decoders and encoders based on Rust png crate
  • SkPngRustDecoder and SkPngRustEncoder
  • png version: 0.17.16; fdeflate version: 0.3.7; see also Chromium’s Cargo.lock. TODO: edit this when M134 branch is created.
  • Chromium turns on the unstable crate feature of the png crate (i.e. uses std::simd in the png crate and specialized instructions in crc32fast crate). (In general, Chromium uses “nightly” versions of rustc and clang as soon as they pass project-specific tests.)

Q: Can you share performance results from the field trials?

Yes, I plan to share aggregate performance numbers. OTOH, I want to wait until we have results from the Stable channel, because:

• The bigger user population of the Stable channel helps to get more statistically significant results (e.g. tighter confidence intervals).
• The numbers need to go through an internal review before being approved for sharing externally. (Mostly to double-check that I won’t accidentally share any secret or competitive data like relative user populations on different platforms, and will only share relative rather than absolute counts or times.)

The M133/Canary data does not have great statistical power, but nevertheless seems to show that Rust is a bit slower than C/C++ in the Renderer4.ImageDecodeTaskDurationUs.Png.Software metric. Furthermore this translates into regressions in WebVitals.FirstContentfulPaint4 and WebVitals.LargestContentfulPaint3 metrics which will get scrutinized when deciding whether to ship. I hope to address this by experimenting with different sizes of fdeflate tables (see here and here).

Disclaimer: Let me also note various factors that may impact the performance results (and therefore explain if/why Chromium numbers may not match other measurements):

• Chromium uses a patched version of zlib that uses SIMD for better performance (and therefore other results comparing across libpng and Rust PNG may not necessarily carry over to this A/B experiment in Chromium)
• Chromium uses a non-default -Coverflow-checks=on even in official, release builds. Only fdeflate crate is opted out.
• Palette expansion optimizations in libpng or png crate are not used by SkPngDecoder nor SkPngRustDecoder, because (unlike blink::PNGImageDecoder) Skia applies alpha premultiplication and color space transformations to <=256 pixels of the palette, rather than to N pixels of the image.
• Chromium ships a single binary per platform, which means that the compiler can only target the baseline instruction set. For example, auto-vectorization in Chromium binaries cannot use AVX-512 SIMD.
• Performance measurements are highly sensitive to the data corpus.