Expand X Render extension to be able to composite windows onto one another

[MadLittleMods]

Expand X Render extension to be able to composite windows (or any "picture") onto one another.

Adds to the X Render extension xrender.zig:

• query_pict_formats: Find matching picture formats in order to create a picture
• create_picture: Create a picture from any drawable (like a window or pixmap) for use with the X Render extension
• composite: Composite those created pictures together with a variety of operations

Testing strategy

$ zig run testexample.zig

Notice a small 100x100 snapshot of the root window is copied to our window

Why use composite over copy_area?

When dealing with a normal default situation where our window just inherits 24-bit color depth from the root window, you could also just use the copy_area command for this kind of functionality. But copy_area does not work when there is a depth mismatch, like when you change your window to 32-bit depth for transparency and try to copy from the 24-bit root window. For an example of this, see MadLittleMods/fps-aim-analyzer#5

I'll also briefly explain the motivation for using Xrender to access the window contents. It is perfectly possible to create a GC for a window and use XCopyArea() to copy the contents of the window if you want to use the core protocol, but since the Composite extension exposes new visuals (ones with alpha channels e.g.), there's no guarantee that the format of the source drawable will match that of the destination. With the core protocol that situation will result in a match error, something that won't happen with the Xrender extension.

In addition the core protocol has no understanding of alpha channels, which means that it can't composite windows that use the new ARGB visual. When the source and destination have the same format, there's also no performance advantage to using the core protocol as of X11R6.8. That release is also the first to support the new Composite extension.

So in conclusion there are no drawbacks, and only advantages to choosing Xrender over the core protocol for these operations.

-- https://www.talisman.org/~erlkonig/misc/x11-composite-tutorial/ (original location: http://ktown.kde.org/~fredrik/composite_howto.html)

Dev notes

• The X Rendering Extension protocol docs:
  • https://www.keithp.com/~keithp/render/protocol.html
  • https://www.x.org/releases/X11R7.5/doc/renderproto/renderproto.txt
• XML definitions of the protocol: https://gitlab.freedesktop.org/xorg/proto/xcbproto/-/blob/98eeebfc2d7db5377b85437418fb942ea30ffc0d/src/render.xml
• C library: https://gitlab.freedesktop.org/xorg/lib/libxrender

[MadLittleMods]

Bumped to 8000 because the query_pict_formats response is big (4888 bytes on my system)

[marler8997]

Had a few comments but overall the changes look reasonable and really cool functionality you've added!

[marler8997]

I'm a little confused by this. Doesn't nextReadBuffer already limit the buffer to the maximum length? If not maybe that's a footgun that should be fixed? If we have to add an extra check after reading into a buffer in order to use it correctly, seems like there's a bigger underlying issue that needs addressed.

[MadLittleMods]

Here is what the doc comment suggests:

zigx/x.zig

Lines 2541 to 2545 in 74ffbcb

	/// The caller must check whether the length returned is larger than the provided `buf`.
	/// If it is, then only the first 32-bytes have been read. The caller can allocate a new
	/// buffer large enough to accomodate and finish reading the message by copying the first
	/// 32 bytes to the new buffer then calling `readOneMsgFinish`.
	pub fn readOneMsg(reader: anytype, buf: []align(4) u8) !u32 {