native jpeg encoder and decoder

[totaam]

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...

[totaam]

2017-01-27 06:11:02: antoine uploaded file dec_jpeg.patch (15.8 KiB)

decode jpeg to RGB24

[totaam]

2017-01-27 11:33:03: antoine commented

---

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).

[totaam]

2017-01-30 07:49:17: antoine commented

---

Lots of fixes and related changes:

• encoder added, decoder re-written using turbojpeg (much nicer): r14886, later improved in r14895 + r14897
• zero copy in network layer: r14885

Also found a big bug in opengl backend: r14898 (not sure why it didn't bite before..)

Somewhat related:

• r14887, r14888 import cleanups

---

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)

[totaam]

2017-02-04 08:33:37: antoine uploaded file no-background-colour.png (19.8 KiB)

wiki rendered using the jpeg encoder

[totaam]

2017-02-04 08:34:08: antoine commented

---

Found some visual artifacts as part of testing for #1426: the xpra wiki loses its background colour:
[[Image(no-background-colour.png)]].

[totaam]

2017-02-04 12:12:20: antoine commented

---

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.

[totaam]

2017-02-06 15:55:11: antoine commented

---

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)

[totaam]

2017-02-14 13:48:08: antoine commented

---

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

I get:

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.

[totaam]

2017-06-20 21:01:42: maxmylyn commented

---

Noted that it's speedier and closing.

[totaam]

2017-07-08 14:29:56: antoine commented

---

r16228 fixes the python3 / cairo rendering which was broken by this change (jpeg decoder code should have been added to the superclass)