Q: static compile

[ultrapre]

I statically compiled stellarium in MSVC and got files with size greatly reduced. Using UPX can reduce more (60MB about, comparing with original unpacked Stellarium).
Is it considerable for official release? Maybe some conflicts in third-party libraries, or limit of open source license, I don't know.

[gzotti]

If your changes are else compatible and optional, it may be worth adding them to CMake files and allow such compiles on private basis (with sufficient instructions!). But given these uncertainties, an official release may have to be checked by a lawyer. It may sound lazy, but given the prevailing trends around storage growth where all programs seem grow without limits and auto-update on a weekly basis (some particular SD card writer with minimal GUI: 150MB download?!) I would not deviate from the usual path of dynamical linking to pre-made DLLs unless there is a critical need to do so.

You say by using static versions AND UPX, you reduce from about 400MB installed folder to 60MB? Or just the 70MB .exe+.dll to 60MB, and the 100MB of nebula textures remain untouched? (Maybe it would be more helpful to allow JPG textures?) What is the reduction without UPX? Maybe some users would also like to experiment with UPX, what is your observation with that: what has to be done to pack/unpack, any noticeable delay for unpacking? Can you send instructions to be included in the wiki or User Guide? It may be beneficial for compact systems with too tiny 64GB SSDs.

[ultrapre]

official: removing the assets(data, pics, translation etc.), left 70MB+
static ver: removing the assets(data, pics, translation etc.), left 10-20MB(25 MB before UPX ), with plugins inside exe.(actually it is only one exe, becuase it donnot need appendix dlls from Qt etc)

[gzotti]

OK. Well, a difference from 70 to 20MB (net effect: 400->350MB) may not really be worth the effort for most. But indeed, the package has become quite large in the last few years. Who really suffers from lack of disk space could profit from instructions what non-critical stuff to delete. (This may depend on personal needs and preferences, of course: translation files, nebula textures, skycultures, 3D models, ...) I would add a section to the user guide if you can provide it. Instructions for creation of a private static build would be welcome in the wiki or source/build directory.

[ultrapre]

To be honestly, comparing with some other astronomy software, stellarium with so rich functions should be bigger. (-:
Some games is 10-100 times of size of it.

In fact, it is easy to compile a static version if you master the method of dynamic compilation. Maybe static buidling will take a lot of time to build a static library firstly, that is the key. I need to compare whether there is a difference, maybe the final result is just adding a sentence in the build guide that you can compile statically as simple as.

[ultrapre]

#1366

MSVC2019 static compile result:

stellarium.exe 31.4MB
after using upx: 14.4MB

copy it and SpoutLibrary.dll(This lib is out of compilation) into a folder with assets:
(
data
landscapes
models
nebulae
scenery3d
scripts
skycultures
stars
textures
translations
webroot
)

Because exe will be loaded in ram, I don't feel obvious time delay on starting or running.

[alex-w]

@ultrapre your solution is good for local experiments, but this is not acceptable for automatic creating a signed packages for distribution (we use AppVeyor for create a distribution packages + SignPath to signing of those packages) 😕

[ultrapre]

I would add a section to the user guide if you can provide it.

@gzotti
I compressed the images of nebulae, and its size reduces from 99.8MB to 16.8MB. Nebulae images don't need alpha channel (maybe).
How much data lost is hard to be found by eyes, and I have tried to use it on Stellarium Android fix. The final apk's size is just 150MB, great progress.

[gzotti]

You can in fact replace all non-transparent textures (esp DSO images and planet textures) from PNG to JPG format. (Of course, rename the texture names in the json where they are configured.) I assume the pictures were originally JPG but there were technical limitations years ago which forced us to use only PNG. Just keep them at good quality.

You can also remove one of the top features, internationality (translations), and build a much more compact English-only version, in addition to the translatable.

The Android build would esp. need a completely different new GUI better suited for small touch screens.

[alex-w]

Nebulae images don't need alpha channel (maybe).

As far I know DSO textures need alpha channel

[gzotti]

No, I have done such a conversion to JPG for a test, and all was nice. They need to have solid black background. See even a warning in SUG section 8.2.1:

Do not use “transparent” pixels available in the PNG format as they will show as white, not black, in Stellarium.

The semitransparent blending is done by the drawing operator.

In effect, I think we should leave PNG so not to blowup the repository even more, but we could use high-quality JPG with their usually still better compression in future textures. Having to convert DSO images from already existing JPG (with any possible losses) into PNG seems a bit weird.

[alex-w]

No, I have done such a conversion to JPG for a test, and all was nice. They need to have solid black background. See even a warning in SUG section 8.2.1:

Yes, you are right! It's my mistake.