WIP: Read 10-bit buffers and save 16-bit screenshots

[mstoeckl]

This makes it possible to take screenshots when the compositor has >10 bit output. See also issue #95.

Marked WIP, since it requires Cairo >= 1.17.2 to build, and a bug fix in cairo to run correctly that will probably only be available when Cairo 1.18.0 is released in a few months. Also, 1.17.2 is a development snapshot, and many distributions are still on the most recent official release, 1.16.0.

To test, modify wlroots to select 10-bit formats for one of the backends; for example, see swaywm/wlroots@2eb44bb .

[mstoeckl]

Right now, grim only uses two parts of Cairo -- the routines to save an image to PNG, and the code in render.c which copies the transformed buffers from the outputs onto a single surface. There are already reasons to have grim use its own PNG saving logic. When it comes to drawing transformed images, Cairo essentially is a thin wrapper around Pixman.

This code in this PR is already somewhat inelegant to adapt to Cairo's limited format support; it requires a separate format conversion stage before the buffer for an output can be drawn, and stores channels as 32 bit floats instead of something more compact. Even the existing code does preprocessing when it channel swaps XBGR8888 buffers. If Pixman's composite API were to be used directly, all this format conversion could be avoided, because Pixman has formats that exactly match XBGR8888 and XBGR2101010.

In other words, the approach currently taken by this PR may not be worth it; it may be better to switch from Cairo to using Pixman directly, and thereby avoid writing format conversion code here that already exists inside Pixman.

[emersion]

Dropping Cairo indeed sounds like a good idea!

[emersion]

This can be closed now I think?

[mstoeckl]

Yes, it's been superseded. (Mostly -- grim currently saves 8 bpc PNG files instead of 16-bpc when the buffers are 10-bpc, but I think it's best to wait on fixing that until Pixman adds support for 16-unsigned formats.)