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
