I was curious to see how well or badly this would perform...
And it turns out that it isn't even stable enough to run the performance tests. That answers it.
adds support for jpeg2000 via PIL
Turns out that it is supported in pillow: jpeg-2000.
The (totally not obvious) reason why we get this error with it:
(...) packages/xpra/server/window/window_source.py", line 2008, in make_data_packet ret = encoder(coding, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 2120, in pillow_encode return self.enc_pillow.encode(coding, image, q, s, transparency) File "/usr/lib64/python2.7/site-packages/xpra/codecs/pillow/encode.py", line 190, in encode im.save(buf, pil_fmt, **kwargs) File "/usr/lib64/python2.7/site-packages/PIL/Image.py", line 1928, in save save_handler(self, fp, filename) File "/usr/lib64/python2.7/site-packages/PIL/Jpeg2KImagePlugin.py", line 264, in _save ImageFile._save(im, fp, [('jpeg2k', (0, 0)+im.size, 0, kind)]) File "/usr/lib64/python2.7/site-packages/PIL/ImageFile.py", line 495, in _save raise IOError("encoder error %d when writing image file" % s) IOError: encoder error -2 when writing image file
Is that there is an undocumented size constraints on images, which must be at least 32x32 in size.
So r17521 adds "jpeg2000" encoding but only uses as a last resort for now, and only when we know for sure that the image will be bigger than 32x32. It does seem to compress quite well, and not too slowly either.
Since we handle encode and decode via pillow, we now also have a way to completely skip "jpeg2000" from the pillow test encode and decode that occurs during codec probing. This may be useful if we encounter crashes or incompatibilities, default values shown:
@maxmylyn: just a FYI, feel free to close.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/618