[Spice-devel] Jpeg support

[Yonit Halperin]

This patch introduces Jpeg encoding/decoding support, for improving Spice WAN experience.
Jpeg encoding is enabled when the connection is a low bandwidth one (and the compression
method is AUTO_GLZ).
Only images that are identified as picture-like are encoded by Jpeg.
When a qxl command components are surface areas or cache items that were sent lossy
to the client, and rendering the command using them might result in a noticeable artifact,
images are resent lossless to the client.

On average usage, this patch improves the bandwidth usage.
However there may be scenarios where the bandwidth usage can get worse. For example,
if a guest program performs draw copy of image B on surface X, and it is sent lossy to the client,
and then the program repeatedly performs:
1) draw_copy part of surface X to surface Y
2) Operation on the copied area on surface X which requires lossless resending (e.g.,
   DRAW_ROP3 command).
Additionally, since the compression is lossy, and we heuristically decide when to use Jpeg, artifacts may still occur.

Future Jpeg tasks:
- control enabling/disabling Jpeg via Qemu command line and monitor, and support
  such state changes during a connection.
- Jpeg support of RGBA bitmaps (encoding the RGB channels using Jpeg, and the alpha channel using a lossless method).
- use libjpeg-turbo when possible. Except from its obvious performance advantage,
it will spare us from converting BGR to RGB and BGRX to RGB.
- Optimizations. Such as:
  * tracking and identifying surfaces (which are not primary) that tend to be used, not necessarily directly,
    for qxl commands that require lossless components. Such surfaces can be resent losslessly.
  * heuristic for identifying composite images, i.e., such that are actually composed from
    distinguishable parts. We should avoid compressing such images using Jpeg, since the
    borders between the image parts can be smeared by Jpeg, and operations that take
    only part of such images may result in artifacts.
  * When we need to resend surface areas, the server might not hold these bitmaps in the version
    required by the client (since more recent commands were rendered). In such cases, I replaced
    all the pipe items that were already rendered with a DRAW_COPY commands of the relevant surfaces areas.
    By taking into consideration the dependencies among these items, and also merging DRAW_COPY commands together,
    we may be able to reduce the count of replaced pipe items.

Cheers,
Yonit.