Re: [Qemu-devel] [RfC PATCH 0/5] console: qom-ify & extent screendump monitor command

[Gerd Hoffmann]

  Hi,

>> True, but I'm not sure we want to go there.  We'd need to add support
>> for options like JPG quality factor etc.
> 
> PNG would be extremely handy and would go a long way to eliminating the
> concern about size.  We already link against libpng too.

vnc uses libpng when available, but it isn't mandatory today.

So we have the choice to (a) make it a hard dependency or (b) make png
support optional.  (b) pretty much implies that nobody will use it
because they can't depend on it being available, so it's largely pointless.

> You can imagine an interface like:
> 
> { "type": "Blob",
>   "data": { "format": "DataFormat", "data": "str" } }
> 
> ...
> 
> { "union": "ImageOptions",
>   "data": { "ppm": "PPMOptions", 
>             "png": "PNGOptions" } }
> 
> { "command": "display-get-screenshot",
>   "data": { "id": "str", "*ImageOptions": "options",
>                            "*format": "DataFormat" },
>   "returns": "Blob" }

> I think it's worth implementing.  A local screenshot I have is 2.3Mb as
> a PPM but only 320k as a PNG.

I don't think it is useful to send image files as base64 over qmp.

We should either send the image file to a file (or filehandle via
fdset).  This would be very simliar to the current screendump command,
and libvirt can easily wind up a pipe to tools like cjpeg or just ask
qemu to dump into a file.

Or we'll go send the raw pixel data over qmp, maybe with optional
compression, so the receiving side doesn't has to bother with decoding
some image file format, like this:

{ "type" : "DisplayContent",
  "data  : { "width"       : int,
             "height"      : int,
             "data"        : str }

cheers,
  Gerd