Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Currently images are recompressed on every rebuild. This is obviously not necessary and is unnecessarily time-consuming.
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
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.
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.
*** Bug 2177 has been marked as a duplicate of this bug. ***
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...
I prefer the 2nd option, taking advantage of the dependency checking.. it's more clean
Here is an open-source alternative to pngcrush: http://imageoptim.com/
Is there any advantage to using that instead of just calling the pngcrush that Apple ships?
*** Bug 4671 has been marked as a duplicate of this bug. ***
Michael, according to this site:
the advantage can be substantial.
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 :)
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?
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
Any progress on this? It would make big difference to most teams working with monotouch I think.
yes, should be the top priority, monotouch is very paintfull to use cause of that..
fixed for MonoDevelop 4.0 (we also don't re-crush plist or strings files)
cool, but when will we see it ?
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..
I think just a few weeks. QA is about to start banging on release candidates.