Re: [gtk-vnc-devel] [PATCH 2/7] Add support for LastRect encoding 2008-11-20 Federico Mena Quintero <federico novell com>



On Thu, Dec 18, 2008 at 08:20:33PM +0100, Peter Rosin wrote:
> Den 2008-12-18 17:27 skrev Daniel P. Berrange:
> >I'm not entirely clear what this encoding does ? It seems to
> >be just a no-op update, and break out of processing the rects
> >off the wire.
> 
> That fits my understanding as well.
> 
> >But if the sever has sent n_rects=16 and this ooccurs as the
> >8th rect, why didn't the server just send 8 rects in the first
> >place ? What happens to the rest of the data on the wire for
> >the remaining rects in this update once we break out of the 
> >loop. We surely need to still consume them off the wire ?
> 
> I believe the idea is that the server can start sending the
> update before it knows exactly how many rects it will need for
> the update. It can thus state that the update will contain at
> least some number of rects (probably 65535) and then end the
> update at will later. So, there is no need to consume the
> trailing rects, the server is not supposed to add any rects
> after the "last rect". I imagine that in this specific case
> e.g. a ptr movement rect can be inserted in the middle of a
> number of tight rects, even if the ptr movement happened after
> the update "started".

Ah ha! That explains things very nicely. 

ACK to Federico's patch then, provided we add this explanation in a
comment at the 'break' statement so we remember just why it works :-)

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]