I just run tools/png-recompress.sh to save some bits. The size of profile/webapps on my laptop is: before: 57.4mb after: 54.6mb So a 2.8mb delta which should be good for the 100mb limit of some system/ partition.
Why don't we run that each time we build, since we are unable to ensure that people recompress png before landing?
It's slow... Fabrice I can not attach the patch to bugzilla as is it a 65mb patch. Please look it at: http://vingtetun.org/tmp/png-recompress.patch It is just binary diff though.
Just submit a PR, r=me and merge
Got it, I'm going to do this right away.
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Created attachment 8360251 [details] [review] [PULL REQUEST] Recompress all PNG assets I've recompressed all relevant PNG assets in this PR, this includes: - all application assets split into one patch per application to simplify using the GitHub side-by-side comparisons to ensure that the compression programs did not introduce artefacts - all shared assets in another patch - I've also fixed a small issue in the png_recompress.sh script that would skip the last file in a directory when invoked in recursive mode, this is also done in a separate patch I did not compress test assets nor assets in the test_apps and showcase_apps folders. Here's a quick comparison of the applications ZIP file size before and after the recompression (done when building in production mode, sizes in KiB): Application Before After Improvement bluetooth 152 120 21% browser 472 352 25% calendar 484 436 10% camera 264 244 8% clock 1324 1148 13% communications 3392 2376 30% costcontrol 456 388 15% email 1008 956 5% fl 160 132 18% fm 220 152 31% gallery 412 352 15% homescreen 612 548 10% keyboard 8056 8004 1% music 1032 992 4% pdfjs 660 628 5% ringtones 1948 1928 1% search 16 16 0% setringtone 84 76 10% settings 2712 2644 3% sms 488 396 19% system 3108 2448 21% video 312 276 12% wallpaper 3828 3724 3% wappush 152 124 18% In some case the improvement is large enough that we should be able to measure an improvement in startup times caused by a reduction in time spent in the zlib/png decompression routines.
Attachment #8360251 - Flags: review?(fabrice)
Comment on attachment 8360251 [details] [review] [PULL REQUEST] Recompress all PNG assets I'm curious to see if we save some load time somewhere.
Attachment #8360251 - Flags: review?(fabrice) → review+
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #6) > I'm curious to see if we save some load time somewhere. Thanks for the review! Merged in gaia/master d16e6c070f1ac139b65f559edd5e3f7e1a8f2ee0
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Steven, please be aware of this patch, thanks! I am happy to verify APNG files stays intact!
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #8) > I am happy to verify APNG files stays intact! APNG files should be unaffected; I have special-cased them so that they don't get stripped of the animation frames accidentally, see the code here and in the lines below: https://github.com/mozilla-b2g/gaia/blob/master/tools/png_recompress.sh#L202
James, Please take it if there's still ROM size problem. Thanks!
Flags: needinfo?(styang) → needinfo?(james.zhang)
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #2) > It's slow... As what Vivien said, it's slow when running these commands. Is there any plan that we will run this command once monthly or quarterly ? (Although we can put this command under git hook when committing any changes but it would also make developers feel painful when waiting for it.) Any idea ?
(In reply to EJ Chen [:eragonj] from comment #11) > Any idea ? I'm trying to spread the word about using this before committing new PNG files and at the same time I'm also monitoring PRs including new PNGs and asking the authors to recompress before landing (or after if it's already too late). One thing we could do is adding a pre-commit hook that runs it on new or modified PNG files in a commit and warn the user if the files should be compressed. This however would assume that everybody has the necessary tools installed.
(In reply to Steven Yang [:styang] from comment #10) > James, > Please take it if there's still ROM size problem. Thanks! OK, ROM size is not critical issue now.
Whiteboard: [tarako] → [tarako][~3MB ROM size]
(In reply to James Zhang from comment #13) > (In reply to Steven Yang [:styang] from comment #10) > > James, > > Please take it if there's still ROM size problem. Thanks! > OK, ROM size is not critical issue now. Good to know! Does that mean that we'll have no problem installing gaia in the /system partition?
blocking-b2g: --- → 1.3T+
Whiteboard: [tarako][~3MB ROM size] → [~3MB ROM size]
Hi Ying Xu, heard that you will be doing uplifts to 1.3T branch. After you completed the uplift, can you please set status-b2g-v1.3T to fixed? please let us know if you have problems with it. thanks
OK, That's about 1800 files to be merged into v1.3t I think we can run tools/png-recompress.sh with user compile config or some other config?
(In reply to ying.xu from comment #16) > I think we can run tools/png-recompress.sh with user compile config or some > other config? What do you mean? Do you want to run png-recompress.sh at build time? If that's the case I wouldn't recommend it as it will take a *long* time to process all images in gaia.
(In reply to Gabriele Svelto [:gsvelto] from comment #17) > (In reply to ying.xu from comment #16) > > I think we can run tools/png-recompress.sh with user compile config or some > > other config? > > What do you mean? Do you want to run png-recompress.sh at build time? If > that's the case I wouldn't recommend it as it will take a *long* time to > process all images in gaia. OK, Ying please merge.
I am currently re-compressing files and will uplift this bug to 1.3t.
status-b2g-v1.3T: ? → fixed
You need to log in before you can comment on or make changes to this bug.