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



On Thu, Nov 20, 2008 at 01:15:36PM -0600, Federico Mena Quintero wrote:
> 	Add support for LastRect encoding to make life easier (?) on the
> 	VNC server.
> 
> 	* src/gvnc.h (gvnc_encoding): Define GVNC_ENCODING_LAST_RECT.
> 
> 	* src/vncdisplay.c (vnc_coroutine): Advertise
> 	GVNC_ENCODING_LAST_RECT as a supported encoding.



> diff --git a/src/gvnc.c b/src/gvnc.c
> index 9cf1204..ba689fa 100644
> --- a/src/gvnc.c
> +++ b/src/gvnc.c
> @@ -2022,7 +2022,7 @@ gboolean gvnc_server_message(struct gvnc *gvnc)
>  	switch (msg) {
>  	case 0: { /* FramebufferUpdate */
>  		uint8_t pad[1];
> -		uint16_t n_rects;
> +		int n_rects;

Why this change ? THe value being read is an unsigned int16

                n_rects = gvnc_read_u16(gvnc);


>  		int i;
>  
>  		gvnc_read(gvnc, pad, 1);
> @@ -2037,6 +2037,11 @@ gboolean gvnc_server_message(struct gvnc *gvnc)
>  			h = gvnc_read_u16(gvnc);
>  			etype = gvnc_read_s32(gvnc);
>  
> +			if (etype == GVNC_ENCODING_LAST_RECT) {
> +				GVNC_DEBUG ("FramebufferUpdate(LastRect)\n");
> +				break;
> +			}
> +

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.

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 ?

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]