This will speed things up as we can use zero copy upload to the opengl backend directly as YUV data. The Python Pillow module just doesn't give us YUV...
decode jpeg to RGB24
Decoder added in r14863 + r14864, including build file updates and packaging.
It paints directly using YUV if the opengl backend is present (otherwise it is unused).
The new module should build out of the box on Fedora and centos. (opensuse will need a specfile update). It builds and runs fine on win32 as mingw-w64 already included everything we need.
OSX has the
libturbojpeg.dylib but not the matching pkgconfig file. I've created one by hand, it builds with warnings (probably an older version of libjpeg-turbo that we should update) - but the packaging step forgets it?
The encoder shouldn't be too difficult to add. I don't think we want to go through the pain of hooking our own CSC module so we'll use the built-in libjpeg-turbo version, which is probably plenty fast already. We should be getting zero-copy transfers from the XSHM, and we will be able to choose the subsampling based on the speed setting (which pillow did not do for us).
Lots of fixes and related changes:
Also found a big bug in opengl backend: r14898 (not sure why it didn't bite before..)
Ready for testing: the jpeg decoder and encoder should now be faster. BUT, we were previously always using YUV420P with the pillow based encoder whereas now we choose the pixel subsampling based on the quality setting. So this may actually be slower at higher quality settings. (the opengl backend should paint more quickly as it paints using YUV directly, this may also affect the html5 client.. we may want to lower / adjust the jpeg quality settings for it)
wiki rendered using the jpeg encoder
Found some visual artifacts as part of testing for #1426: the xpra wiki loses its background colour: .
I suspect that the YUV output uses a different range than what we are used to with the avcodec and vpx output, so r14974 disables the YUV jpeg decoder until I can figure this out.
This new codec help uncover 2 very serious issues, fixed in r14990 + r14991. Also needed r14989 to close the context and avoid a memory leak. Minor improvements in r15000, r15001 (opengl paint debugging)
I give up on decoding to YUV: moved to #1438.
As of r15061 + r15062, we use this new decoder to RGB with both opengl and pixmap backings.
@afarr: this is mostly a FYI. This new codec is faster, that is all. You can see the compression performance server side with "-d compress", client side with:
XPRA_JPEG_LOG_PERF=1 xpra attach --encodings=jpeg -d jpeg
decompress_to_rgb: size=694x244, subsampling=444, colorspace=YCbCr decompress jpeg to BGRX: 869 MB/s ( 677344 bytes in 0.7ms) decompress_to_rgb: size=694x244, subsampling=444, colorspace=YCbCr decompress jpeg to BGRX: 461 MB/s ( 677344 bytes in 1.4ms)
~400 to 900 MB/s is quite impressive.
Noted that it's speedier and closing.
r16228 fixes the python3 / cairo rendering which was broken by this change (jpeg decoder code should have been added to the superclass)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1423