Re: [Qemu-devel] [PATCH v2 08/18] vnc: tight add PNG encoding

[Corentin Chary]

On Thu, Jul 8, 2010 at 3:19 PM, Daniel P. Berrange <address@hidden> wrote:
> On Thu, Jul 08, 2010 at 03:10:31PM +0200, Corentin Chary wrote:
>> On Thu, Jul 8, 2010 at 11:48 AM, Daniel P. Berrange <address@hidden> wrote:
>> > On Wed, Jul 07, 2010 at 08:57:56PM +0200, Corentin Chary wrote:
>> >> Introduce a new encoding: VNC_ENCODING_TIGHT_PNG [1] (-269) with a new
>> >> tight filter VNC_TIGHT_PNG (0x0A). When the client tells it supports the 
>> >> Tight PNG
>> >> encoding, the server will use tight, but will always send encoding pixels 
>> >> using
>> >> PNG instead of zlib. If the client also told it support JPEG, then the 
>> >> server can
>> >> send JPEG, because PNG will only be used in the cases zlib was used in 
>> >> normal tight.
>> >
>> > I know that VNC_ENCODING_TIGHT_PNG / -260 is already allocated to
>> > QEMU in the RFB specification. Who is the authority for allocating
>> > tight filter numbers, and have they recorded/approved use of 0x0A
>> > for this PNG capability ?
>> >
>>
>> Tight PNG should considered as a new encoding, not as a tight pseudo 
>> encoding.
>> When using Tight PNG, the server will send rect updates with -260, not 7.
>
> Why layer this into the rest of the Tight protocol decoding then ? What
> benefit does it offer over a more straightforward standalone "PNG" encoding,
> that was completely independant of any tight based encoding.
>

Because:
- we also want a lossy encoding (Jpeg) for some parts (adaptive choice
between jpeg and png/zlib based on update frequency is comming soon).
- we want the "fill" encoding for solid color rectangles

A standalone "PNG" encoding would work for some use case, and could be
added later, but Tight PNG is more than that.




-- 
Corentin Chary
http://xf.iksaif.net