Re: [gtk-vnc-devel] [PATCH 2/7] Add support for LastRect encoding 2008-11-20 Federico Mena Quintero <federico novell com>
- From: "Daniel P. Berrange" <berrange redhat com>
- To: Peter Rosin <peda lysator liu se>
- Cc: gtk-vnc-devel lists sourceforge net
- Subject: Re: [gtk-vnc-devel] [PATCH 2/7] Add support for LastRect encoding 2008-11-20 Federico Mena Quintero <federico novell com>
- Date: Thu, 18 Dec 2008 20:10:00 +0000
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]