It was removed in r14508 as part of a codec cleanup. The main problems with it were that:
After playing with it on Fedora 27 with libwebp 0.6.0, it seems that there are settings we can use that will give us better compression and better performance than png. And we should be able to avoid using it for the cases where it isn't adequate.
We need something better than png to avoid using up all the bandwidth with lossless refresh. (see ticket:999#comment:20 for details)
A very quick and dirty test with glxspheres at 1240x900 with speed=100 and quality=100 shows:
The pillow webp code is much slower (~100ms), but it also compresses better: the size is just 2.5%! So clearly we can do better with this codec, I'm just not sure how yet. Undoing all the configuration we do, the same image takes 2 seconds to compress! (and the gains really aren't worth it: only 6.5% compression ratio)
Here are the settings that we use when trying to go for maximum lossless compression:
webp.compress used config: {'emulate_jpeg_size': 0, 'filter_sharpness': 0, 'thread_level': 1, \
'autofilter': 1, 'pass': 1, 'alpha_filtering': 0, 'sns_strength': 0, \
'target_PSNR': 0.0, 'low_memory': 0, 'show_compressed': 0, 'target_size': 0, 'method': 0, \
'filter_type': 1, 'preprocessing': 0, 'alpha_compression': 0, 'alpha_quality': 0, \
'partition_limit': 0, 'lossless': 1, 'partitions': 3, 'filter_strength': 0, 'image_hint': 'graph', 'segments': 2}
The only major problem with this is that my xterm window comes out all black. (but the glxspheres window looks fine!)
Sadly, detect webp support.
doh: we were forcing speed=100 when quality=100 (lossless).
Hardcoding the "method" to 0 (fast) and lossless mode (quality=100), we can fine tune the time spent compressing by setting webp's "quality" attribute (which has nothing to do with quality in this case..) - but the resulting output size remains pretty much the same! Setting the method to 1 or higher and the compression becomes too slow (250ms or more), for only 1 percentage point of extra compression! The reason why Pillow was doing better is that it wasn't doing true lossless as the quality value was clamped to 99 in our code!
re-adds webp and makes it fast!
In debug mode, webp is shown using a pink contour colour as before. All builds should have the correct dependencies added, including macos and win32 builds.
@maxmylyn: mostly a FYI, testing wouldn't hurt but feel free to just close.
I don't think this is needed as long as pillow doesn't link with libwebp
Updates:
Interesting thing I spotted during bandwidth tuning for #999, webp can compress the xterm in lossless mode 40 times better than when using lossy compression!
compress: 10.5ms for 499x316 pixels at 0,0 for wid=1 using webp \
with ratio 23.0% ( 615KB to 141KB), sequence 74, \
client_options={'quality': 99, 'speed': 97, 'rgb_format': 'RGBX'}
compress: 2.6ms for 499x316 pixels at 0,0 for wid=1 using webp \
with ratio 0.6% ( 615KB to 3KB), sequence 75, \
client_options={'quality': 100, 'speed': 50, 'rgb_format': 'RGBX'}
Time for some window hints to make better guesses at what compression to use: #1699.
r17541: libwebp 0.6.1
Noted. I'll also make a note to myself to add it to the test box.
Closing.
Found a bug with the non-opengl rendering: the red and blue channels would end up swapped. That's because the webp encoder compresses BGRA (or BGRX) as input, so if it was fed "RGBA" (or "RGBX") then we have to swap the channels when decoding. The correct fix is a bit long but it does make sense: r17688.
r17697 is a more complete end-to-end fix: the client tells the server which RGB modes it can handle for webp.
This fixes the potential problem where the HTML5 client would be asked to decode a swapped-channels-webp image. This could happen if we had a server that fed "RGBX" (or "RGBA") to the encoder instead of "BGRX" (or "BGRA"). ie: maybe on a little endian arch?
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1694