koobas.hobune.stream
How to safely manage 100 large JPEGs in a picture viewer app
So here is my problem, and I need a conceptional solution for it.
I'm having 100 JPEGs to show in a picture viewer app. Every JPEG is up to Retina resolution so might have 2880x1800. My Asset folder is 100 MB, which is the total size of the compressed JPG files. I put all those textures into a Resources folder and enabled automatic compression in the texture properties. Now I made a test build for Android and got a shocking 1.3GB large APK. Question - why can't textures not be saved in a compressed manner like they can on disk? Why do 100MB of input files result in a Gigabyte of APK, which is also compressed?? I do understand that the factual VRAM usage would be several Gigabytes of course, but why the package? The only solution for me would be to host the JPEGs on a server and load them (even though that leads to ugly breaks in interactivity of several seconds whenever a texture gets initialized due to single-threading in unity). And if I do that - how does unity manage the memory when I load texture after texture (but unloading objects once no longer displayed)? Will I run into problems which will make the app crash after some textures were loaded? How in the world can such an app be realized at all? I'm seriously thinking about using PhoneGap and create a stupid HTML-App, since it apparently is much more capable than unity to manage such a task, even though animations would be more difficult. Any ideas how to safely do that in unity? Many thanks, frevd
Did you look at your build log and see if there are other unintended elements in Resources (or subfolders of Resources) that is artificially driving your size up?
try to check texture Import settings: 1.disable Read/Write Enable 2.disable Generate$$anonymous$$ip$$anonymous$$pas
Oh right, thanks for the hint. The build takes an hour or so, so I didn't try often. Read/write was disabled and the $$anonymous$$ip$$anonymous$$aps I need to display pictures in various sizes, even though using GUI.DrawTexture. However, Textures are NPOT (not square and not power-of-2).
The log file says:
Textures -1346028.3 kb 100.6%
$$anonymous$$eshes 0.0 kb -0.0%
Animations 0.0 kb -0.0%
Sounds 0.0 kb -0.0%
Shaders 0.0 kb -0.0%
Other Assets 480.8 kb -0.0%
Levels 25.1 kb -0.0%
Scripts 10.8 kb -0.0%
Included DLLs 4.9 mb -0.4%
File headers 2.0 mb -0.2%
Complete size -1338458.1 kb 100.0%
Used Assets, sorted by uncompressed size:
46.5 mb -3.6% Assets/Resources/_Torre_16.jpg
...
31.6 mb -2.4% Assets/Resources/2012_04_03__caracas_00326.jpg
...
21.5 mb -1.6% Assets/Resources/Floor_Plans_All.jpg
...
14.0 mb -1.1% Assets/Resources/2011_05_06__caracas10_00592.jpg ...
9.6 mb -0.7% Assets/Resources/UTT_$$anonymous$$C_Section_La_Ceiba.jpg
...
*** Completed 'Build.Player.AndroidPlayer' in 2396 seconds
Something is wrong here definitely.
Ugly hack: There should be a way to include files with the build such that they appear at the Application.persistentDataPath of the build on Android (I can on iOS). If so, then you can use the WWW class to load the images.
Okay, seems the problem is the NPOT thing.
