Bug 1587 - Images should only be re-compressed if they've changed
Summary: Images should only be re-compressed if they've changed
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: unspecified
Hardware: PC Windows
: Normal enhancement
Target Milestone: ---
Assignee: Jeffrey Stedfast
: 2177 4671 ()
Depends on:
Reported: 2011-10-19 17:16 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2013-01-17 07:36 UTC (History)
8 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Rolf Bjarne Kvinge [MSFT] 2011-10-19 17:16:35 UTC
Currently images are recompressed on every rebuild. This is obviously not necessary and is unnecessarily time-consuming.
Comment 2 Mikayla Hutchinson [MSFT] 2011-10-19 17:30:26 UTC
That's because we use iphone-optimize on the compiled app and it's not very smart.

There are a few ways we could improve this:
1) make optimization optional, only enable on release builds
2) re-implement iphone-optimize (it's pretty much just calling external tools) and take advantage of our dependency checking, e.g. individually pngcrush images only after copying them into the app
Comment 3 kenny goers 2011-10-20 09:07:15 UTC
Off by default on debug builds would be fantastic as it's probably not needed, and being able to turn off entirely would be great, our graphics artists generally optimize them as they generally go to the web as well as in the app.
Comment 4 Mikayla Hutchinson [MSFT] 2011-10-20 11:55:03 UTC
Well, in theory the pngcrush makes images deploy and load faster on device, so if we supported doing it incrementally (for modified images only) it would still be useful for debug builds.
Comment 5 Mikayla Hutchinson [MSFT] 2012-01-20 11:47:57 UTC
*** Bug 2177 has been marked as a duplicate of this bug. ***
Comment 6 renan jegouzo 2012-01-30 23:31:15 UTC
would be nice to make the resolution of this bug a top priority, on project like games or books, it makes
 mono touch unusable cause of too long build time...
Comment 7 renan jegouzo 2012-01-30 23:40:43 UTC
I prefer the 2nd option, taking advantage of the dependency checking.. it's more clean
Comment 8 Rolf Bjarne Kvinge [MSFT] 2012-04-23 12:47:41 UTC
Here is an open-source alternative to pngcrush: http://imageoptim.com/
Comment 9 Mikayla Hutchinson [MSFT] 2012-04-23 18:54:32 UTC
Is there any advantage to using that instead of just calling the pngcrush that Apple ships?
Comment 10 Mikayla Hutchinson [MSFT] 2012-04-26 13:28:58 UTC
*** Bug 4671 has been marked as a duplicate of this bug. ***
Comment 11 Rolf Bjarne Kvinge [MSFT] 2012-04-26 17:00:27 UTC
Michael, according to this site:


the advantage can be substantial.
Comment 12 Nic Wise 2012-04-27 09:54:03 UTC
I'd love to see some movement on this, as I have a VERY PNG-heavy app, and a designer pushing me to make it smaller :)
Comment 13 Rolf Bjarne Kvinge [MSFT] 2012-04-27 09:59:11 UTC
Another way of fixing this (at least to some extent) is to make it possible to disable the optimization (so the user can add already optimized images to the project), maybe by adding another BuildAction for pngs?
Comment 14 Mikayla Hutchinson [MSFT] 2012-04-27 12:47:18 UTC
The build action would technically be a clean way to implement the feature so it could be enabled on an image-by-image basis, but I think it would be confusing, and it wouldn't have a global toggle.

I would suggest that we do three things:
* add have an OptimizeBundleResources per-config build setting to disable the compression, and UI for it
* re-implement iphone-optimize by having the MD build run pngcrush/plutil to optimize png/plist content as it copies them into the bundle. This will take advantage of existing dependency checking.
* when we have the BundleResource build action, add support for disabling optimization on a per-file basis with <Optimize>False</Optimize> metadata
Comment 15 Andreas Larsen 2013-01-13 04:09:09 UTC
Any progress on this? It would make big difference to most teams working with monotouch I think.
Comment 16 renan jegouzo 2013-01-14 18:27:26 UTC
yes, should be the top priority, monotouch is very paintfull to use cause of that..
Comment 17 Jeffrey Stedfast 2013-01-16 17:55:04 UTC
fixed for MonoDevelop 4.0 (we also don't re-crush plist or strings files)
Comment 18 renan jegouzo 2013-01-17 03:08:10 UTC
cool, but when will we see it ?
Comment 19 renan jegouzo 2013-01-17 03:10:50 UTC
really but it's nice, I think I have lost an entire month of my life the last 2 years, at waiting during the crushing times..
Comment 20 Jeffrey Stedfast 2013-01-17 07:36:33 UTC
I think just a few weeks. QA is about to start banging on release candidates.