| Message ID | 1274186986-26878-4-git-send-email-corentincj@iksaif.net |
|---|---|
| State | New |
| Headers | show |
Corentin Chary wrote: > According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding > zlib encoding only uses a single stream. Current implementation defines > 4 streams but only uses the first one. Remove them and only use a single > stream. > How about when we start to implement zrle or zhextile? Wouldn't those need different streams? Alex
On 05/18/2010 07:51 AM, Alexander Graf wrote: > Corentin Chary wrote: > >> According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding >> zlib encoding only uses a single stream. Current implementation defines >> 4 streams but only uses the first one. Remove them and only use a single >> stream. >> >> > How about when we start to implement zrle or zhextile? Wouldn't those > need different streams? > Only tight uses multiple streams. zrle just uses one. zhextile doesn't exist and if it did, it wouldn't be better than Tight because Tight is essentially zhextile :-) Regards, Anthony Liguori > Alex > >
Anthony Liguori wrote: > On 05/18/2010 07:51 AM, Alexander Graf wrote: >> Corentin Chary wrote: >> >>> According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding >>> zlib encoding only uses a single stream. Current implementation defines >>> 4 streams but only uses the first one. Remove them and only use a >>> single >>> stream. >>> >>> >> How about when we start to implement zrle or zhextile? Wouldn't those >> need different streams? >> > > Only tight uses multiple streams. zrle just uses one. Ah, that's why I put it in there back then. I see :). Alex
On 05/18/2010 08:52 AM, Alexander Graf wrote: > Anthony Liguori wrote: > >> On 05/18/2010 07:51 AM, Alexander Graf wrote: >> >>> Corentin Chary wrote: >>> >>> >>>> According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding >>>> zlib encoding only uses a single stream. Current implementation defines >>>> 4 streams but only uses the first one. Remove them and only use a >>>> single >>>> stream. >>>> >>>> >>>> >>> How about when we start to implement zrle or zhextile? Wouldn't those >>> need different streams? >>> >>> >> Only tight uses multiple streams. zrle just uses one. >> > Ah, that's why I put it in there back then. I see :). > Keep in mind, tight's 4 streams are not the same as zrle or zlib's 1 stream. A server is free to send both Tight updates and zrle updates if the client supports it. The client is going to expect that zrle is a different compression stream than any of the 4 tight streams. That's why you can't use the Tight compression level selection messages to choose the zlib compression level btw. Regards, Anthony Liguori > Alex > >
Anthony Liguori wrote: > On 05/18/2010 08:52 AM, Alexander Graf wrote: >> Anthony Liguori wrote: >> >>> On 05/18/2010 07:51 AM, Alexander Graf wrote: >>> >>>> Corentin Chary wrote: >>>> >>>> >>>>> According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding >>>>> zlib encoding only uses a single stream. Current implementation >>>>> defines >>>>> 4 streams but only uses the first one. Remove them and only use a >>>>> single >>>>> stream. >>>>> >>>>> >>>>> >>>> How about when we start to implement zrle or zhextile? Wouldn't those >>>> need different streams? >>>> >>>> >>> Only tight uses multiple streams. zrle just uses one. >>> >> Ah, that's why I put it in there back then. I see :). >> > > Keep in mind, tight's 4 streams are not the same as zrle or zlib's 1 > stream. A server is free to send both Tight updates and zrle updates > if the client supports it. The client is going to expect that zrle is > a different compression stream than any of the 4 tight streams. > > That's why you can't use the Tight compression level selection > messages to choose the zlib compression level btw. So patch 4 is invalid? Alex
On 05/18/2010 08:56 AM, Alexander Graf wrote: > So patch 4 is invalid? > Technically, yes although I'm not sure that it would necessarily break a client (since the client's request of compression levels is really just advisory). Regards, Anthony Liguori > Alex > >
diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c index 4a495ad..6a16a79 100644 --- a/vnc-encoding-zlib.c +++ b/vnc-encoding-zlib.c @@ -54,9 +54,9 @@ static void vnc_zlib_start(VncState *vs) vs->output = vs->zlib; } -static int vnc_zlib_stop(VncState *vs, int stream_id) +static int vnc_zlib_stop(VncState *vs) { - z_streamp zstream = &vs->zlib_stream[stream_id]; + z_streamp zstream = &vs->zlib_stream; int previous_out; // switch back to normal output/zlib buffers @@ -70,7 +70,7 @@ static int vnc_zlib_stop(VncState *vs, int stream_id) if (zstream->opaque != vs) { int err; - VNC_DEBUG("VNC: initializing zlib stream %d\n", stream_id); + VNC_DEBUG("VNC: initializing zlib stream\n"); VNC_DEBUG("VNC: opaque = %p | vs = %p\n", zstream->opaque, vs); zstream->zalloc = zalloc; zstream->zfree = zfree; @@ -122,7 +122,7 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) // compress the stream vnc_zlib_start(vs); vnc_raw_send_framebuffer_update(vs, x, y, w, h); - bytes_written = vnc_zlib_stop(vs, 0); + bytes_written = vnc_zlib_stop(vs); if (bytes_written == -1) return; @@ -136,7 +136,5 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) void vnc_zlib_init(VncState *vs) { - int i; - for (i=0; i<(sizeof(vs->zlib_stream) / sizeof(z_stream)); i++) - vs->zlib_stream[i].opaque = NULL; + vs->zlib_stream.opaque = NULL; } diff --git a/vnc.h b/vnc.h index 1aa71b0..dfdb240 100644 --- a/vnc.h +++ b/vnc.h @@ -173,7 +173,7 @@ struct VncState /* Zlib */ Buffer zlib; Buffer zlib_tmp; - z_stream zlib_stream[4]; + z_stream zlib_stream; Notifier mouse_mode_notifier;
According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding zlib encoding only uses a single stream. Current implementation defines 4 streams but only uses the first one. Remove them and only use a single stream. Signed-off-by: Corentin Chary <corentincj@iksaif.net> --- vnc-encoding-zlib.c | 12 +++++------- vnc.h | 2 +- 2 files changed, 6 insertions(+), 8 deletions(-)