If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Don't crush pngs during packaging step

RESOLVED WONTFIX

Status

()

Firefox for Android
Build Config & IDE Support
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: ckitching, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
At the moment, it seems `mach package` runs pngcrush on a bunch of assets, taking a few seconds.

While we want to crush our assets, a better approach might be to check the already-crushed assets into Mercurial, instead of crushing on a per-build basis. That way, we pay the crushing cost only once, not many, many times.
(Reporter)

Updated

3 years ago
Assignee: chriskitching → nobody
I worry about the "check the already-crushed assets into Mercurial" because it depends on humans.

Comment 2

3 years ago
As a short term solution, could we just avoid running png crush for local builds, but still run it on TBPL/release builds?

As a long term solution, we could have a test on TBPL that fails if you check in non-crushed images.
I don't think we should be actively moving our local build more away from TBPL/shipping builds. I also don't see this issue being that big of a deal. I'm going to WONTFIX this unless there is a really good reason to tweak builds.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX

Comment 4

3 years ago
If we could save a few seconds I think we should. Slow packaging time is one of the worst parts of Fennec development for me.

If assets are already crushed, does this step still take the same amount of time? Perhaps we can reach a compromise by fixing the assets that are already in the tree, trying to be diligent about checking in crushed assets, but then still leaving this packaging logic as a back-up.
(In reply to Mark Finkle (:mfinkle) from comment #1)
> I worry about the "check the already-crushed assets into Mercurial" because
> it depends on humans.

This doesn't seem very different from changing the colors of resources as I did in bug 1030748, or even checking in the resources in the first place. Why is this a problem if it only needs to be done once and can additionally be checked on by multiple eyes?
(In reply to Michael Comella (:mcomella) from comment #5)
> (In reply to Mark Finkle (:mfinkle) from comment #1)
> > I worry about the "check the already-crushed assets into Mercurial" because
> > it depends on humans.
> 
> This doesn't seem very different from changing the colors of resources as I
> did in bug 1030748, or even checking in the resources in the first place.
> Why is this a problem if it only needs to be done once and can additionally
> be checked on by multiple eyes?

Can you tell if an image has been crushed from looking at it?
(In reply to Mark Finkle (:mfinkle) from comment #6)
> Can you tell if an image has been crushed from looking at it?

Not directly, but I can go into the filesystem and see the change in file size.
You need to log in before you can comment on or make changes to this bug.