User Agent: Mozilla/5.0 (X11; linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36

Expected results:

This issue tracks the work to replace the current pref disabled C++ JXL decoder with a Rust based JXL decoder.

Creating this issue here after discussing with tnikkel@mozilla.com.

is there a meta bug to follow the work on this? thanks
(or this is the main bug ?)

I guess it depends on what you are interested in tracking. This is the bug to land the changeover from a C++ jpegxl library to a rust jpegxl library. We have bug 1539075 that tracks jpeg-xl overall that is still existing from our initial c++ backed implementation (I'll add this to that bug now). If there is something specific you want to track I can file a new bug as needed.

this is good, thanks
it was to add the release notes item

Release Note Request (optional, but appreciated)
[Why is this notable]: Rust rewrite and tech press loves writing about it
[Affects Firefox for Android]: I guess ?
[Suggested wording]: The jpeg-xl library has been ported to Rust code for better security
(and performance?)

[Links (documentation, blog post, etc)]:

All of this code is only compiled on nightly, and is pref disabled by default there. So I'm not sure a release note is appropriate at this point.

Comment #8 is true, but also there are people who are watching closely, so maybe we can declare this is a special case.

And there's a question worth asking - do we still want to build it only on Nightly or are we okay to build it for stable/beta too? (With the pref disabled, of course)

You can keep "Differential Revision: (URL)" comment in the commit message to prevent recreating the patch.

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #13)

You can keep "Differential Revision: (URL)" comment in the commit message to prevent recreating the patch.

Hm, yes, but when I reordered them it remembered the parentage and everything got very upside down. I removed the later 2 patches and uploaded them anew. I hope that works.

moz-phab reorg is the way to fix that!

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

All of this code is only compiled on nightly, and is pref disabled by default there. So I'm not sure a release note is appropriate at this point.

It doesn't really matter. The goal is to make sure release managers are aware when it is ready and enabled.
(they will know when to add it :)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #16)

moz-phab reorg is the way to fix that!

Ah, I think I tried that, but maybe in the wrong way?

(In reply to Martin Bruse from comment #15)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #13)

You can keep "Differential Revision: (URL)" comment in the commit message to prevent recreating the patch.

Hm, yes, but when I reordered them it remembered the parentage and everything got very upside down. I removed the later 2 patches and uploaded them anew. I hope that works.

You can also always change the order of revisions on the phabricator web ui. We always try not to create new revisions as it loses all of the review state.

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #10)

And there's a question worth asking - do we still want to build it only on Nightly or are we okay to build it for stable/beta too? (With the pref disabled, of course)

I think we should take things one step at a time: keep it on nightly for now, we can make that change at some point after this.

(In reply to Timothy Nikkel (:tnikkel) from comment #19)

(In reply to Martin Bruse from comment #15)

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #13)

You can keep "Differential Revision: (URL)" comment in the commit message to prevent recreating the patch.

Hm, yes, but when I reordered them it remembered the parentage and everything got very upside down. I removed the later 2 patches and uploaded them anew. I hope that works.

You can also always change the order of revisions on the phabricator web ui. We always try not to create new revisions as it loses all of the review state.

Thank you, I'll avoid doing it in the future!

Should we also prepare a new intent to prototype?

For posterity and reference, I'd just like to document here that as of right now, the jxl-rs decoder that we're integrating is not of production performance, It currently decodes ~4M pixels/s on a mediocre laptop, which we expect to improve a lot in the future.

Comment on attachment 9513722 [details]
Bug 1986393 - Added basic CMYK support to the SurfacePipeFactory. r=tnikkel

Revision D265077 was moved to bug 1989218. Setting attachment 9513722 [details] to obsolete.