Similar to #909 but using less bits per pixel.
Not much to be gained from using 16-bit colour instead of 24 bits per pixel. Most libraries will convert to 24-bit internally and very few encoders support 16-bit - apparently, libvpx does. I guess some very specific applications might benefit on very bandwidth constrained links. Or some application may just require those modes?
We could at least handle this a little bit more gracefully than we do now and convert to 24-bit rather than just failing:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/x11/gtk2/window_damage.py", line 171, in get_image shm_image = shm.get_image(handle.get_pixmap(), x, y, width, height) File "xpra/x11/bindings/ximage.pyx", line 561, in xpra.x11.bindings.ximage.XShmWrapper.get_image (xpra/x11/bindings/ximage.c:7071) imageWrapper.set_image(self.image) File "xpra/x11/bindings/ximage.pyx", line 267, in xpra.x11.bindings.ximage.XImageWrapper.set_image (xpra/x11/bindings/ximage.c:2404) raise Exception("invalid image depth: %i bpp" % self.depth) Exception: invalid image depth: 16 bpp
Note: we cannot support 8-bit colour depth (or less) in seamless mode as the X11 server then disables compositing.
r15120 adds support for 16-bit display servers, we convert the pixels to RGB(X) before encoding, only png and rgb encodings are supported in this mode. (and scrolling detection).
8-bit depth (#1445) would be more interesting to support, but it is also harder to implement.
Testing different bit depths is now much easier in r15124, see wiki/ImageDepth.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1315