Build has FAILED

Link to build: http://jw:8080/job/phabricator/1834/
See console output for more information: http://jw:8080/job/phabricator/1834/console

Executing section Default...
Executing section Source...
Executing section JS...
Executing section XML GUI...
Executing section Python...
Executing section Perl...

http://jw:8080/job/phabricator_lint/378/ for more details.

I am not a fan of lossy image compression, jpg also isn't great with non photographic material (e.g. GUI elements).
Also if the screenshot is edited and then resaved again as jpg this introduces a double lossy compression with visible artefacts.

An alternative is generating a BMP file, it should be even faster, and then you can recompress it later as wanted.
Alternatively some settings for libpng compression could be tried:
https://stackoverflow.com/questions/11713895/saving-bmps-as-pngs-with-c-vs-2010-fast?answertab=votes#tab-top

This will also save one dependency, FWIW.

In D779#30842, @fabio wrote:

save one dependency, FWIW.

Sure, that was the original benefit of nuking it.

I am not a fan of lossy image compression

Sure, sometimes we want PNG screenshots. That's why this adds an option to chose between JPG and PNG.

• I couldn't notice any difference between JPG and PNG images, even when zooming in
• For promotional material, the PNG screenshots are still kind of improvable, one should go with the 6400x4600 BMP that was invented specifically for promotional material.

See the a22 release announcement https://play0ad.com/new-release-0-a-d-alpha-22-venustas/ for example.

When zooming it it becomes very noticeable:
1080p:

1080p:

6k zoomed in:

1080p JPG taken with that patch (260kb):

1080p PNG (2.1MB):

An alternative is generating a BMP file, it should be even faster, and then you can recompress it later as wanted.

Saving bitmaps doesn't really help with avoiding useless disk space and time investment.
There is a different use a case between taking screenshots once or twice per year for promotion and taking screenshots often to document whatever is happening on the screen (bugs, interesting game scene, reporting players, nice map, nice feature).
I believe most users do it for the latter, no?
Converting the screenshots later is pointless work, consumes time, scripting, cpu power, attention to check for data loss and it has to be done each time after taking some screenshots (so the disk space is acummulated uselessly by a factor of about 5) . I had patched my
code ever since the original revert to save this work, time and disk space.

Alternatively some settings for libpng compression could be tried:
https://stackoverflow.com/questions/11713895/saving-bmps-as-pngs-with-c-vs-2010-fast?answertab=votes#tab-top

The file size doesn't become smaller as we already use maximum compression.

We should consider the average player, are they going to take the screenshot for promotional material or are they taking the screenshot becaues they want to document the current event?
The screenshots on the forums for example are typically not polished enough to justify lossless quality.
Uploading PNGs that are 4 to 10 times larger also takes 4 to 10 times longer to upload and in the end they are converted to JPEG upstream.

Another use case in the future would be automatic replay thumbnails.

I found the JPEG blockiness around text a bit annoying on the main menu screenshot. Obligatory humour image:

Anyway if we go that route it would be nice to avoid reintroducing old libjpeg on windows and osx, and rather use libjpeg-turbo, also used by most linux distro by now.

If going that way (i don't mind either way), it would be nice to add some hotkey: P+F2 for png and J+F2 for jpg independantly of the option (changing then reverting option when you just need a screenshot with the given format is cumbersome). We could then also add a B+F2 for bmp for consistency.

F2 - JPEG (cause its fastest)
B + F2 - BMP
P + F2 - PNG
(If these shortcuts even possible)
Or f2+b/p

In D779#30863, @ffffffff wrote:

F2 - JPEG (cause its fastest)
B + F2 - BMP
P + F2 - PNG
(If these shortcuts even possible)
Or f2+b/p

Why would you want to impose your preferences? I don't care about fastest, but cares about best quality.
But read again the proposal which was to add these keys to the current patch, so
F2 = what is defined by the user in its options (as done in the current patch) and P/J/B+F2 forces another format without having to change the options.

No idea if this is possible, but having the compression happens in its own thread would not slowdown the game, either PNG or JPEG.

In D779#31167, @fabio wrote:

No idea if this is possible, but having the compression happens in its own thread would not slowdown the game, either PNG or JPEG.

yes ok for some reason thers some lag maybe due to io when first screeny. maybe jpeg smaller files are faster io. must be tested.

game just lags one time maybe with jpeg too. maybe its ok.

In #0ad-dev on 2018-05-13 I briefly considered conditional libjpeg with Itms.
That might make it easier when we want to use that for instance to render trailers with lossless jpeg quality.
Implementation of the old jpeg support on unix and a config option for the quality here:
https://github.com/elexis1/0ad/tree/trailerhacks_a23

The use case to take screenshots of games automatically might still eventually come to players one day though, for instance seeing the highlights of a replay in the replay menu without starting the match, or when implementing an upload button that posts the replay + images to a website.
Since both formats are optionally lossless but one of them stores significantly smaller files, to me the preference is clear, barring maintenance cost and possible library exploits.