Hi Peter, Not quite. The problem you described didn't involve Refresh Screen. In the absence of Refresh Screen, the scheme used by VNC Free Edition & software based upon it works correctly.
Regards, -- Wez @ RealVNC Ltd > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Astrand > Sent: 12 December 2007 18:17 > To: Anon Sricharoenchai > Cc: vnc-list@realvnc.com; [EMAIL PROTECTED] > Subject: Re: pixel format is out of sync, after refreshing > and suddenly changing pixel format > > At a glance, this looks like the same problem I had a few > years ago. See the thread > http://article.gmane.org/gmane.network.vnc.user/18430. (Click > on the subject). > > > Best regards, > Peter Cstrand > > On Wed, 12 Dec 2007, Anon Sricharoenchai wrote: > > > Hi, > > > > I'm not sure to call this a bug in vncviewer, or a bug in > VNC protocol. > > > > Anyhow, this bug apply to realvnc 4.0 to 4.1.1. The bug may > > demonstrate the flaw in VNC protocol, which don't have any > mechanism > > to ensure the synchronization of the pixel format between > client and > > server. > > > > Let's see how to reproduce this bug first, and then see how pixel > > format is out of sync. > > (To view this bug in a clear formatted text, visit > > > http://opensource.wikia.com/wiki/Bugs:realvnc4/pixel_format_is > _unpredictable_ > after_refreshing_and_suddenly_changing_pixel_format > > ) > > > > == How to reproduce == > > Run the following command in some terminal, "terminal1", in this > > example, > > > > terminal1 $ Xvnc :1 -nolisten tcp -auth /dev/null -localhost > > -SecurityTypes=None -geometry 800x600 -depth 24 & > > terminal1 $ DISPLAY=:1 xterm -e perl -e '$|=1; for(;;){print"."; > > select(undef,undef,undef,0.001); }' & > > > > Then open another terminal, "terminal2", run vncviewer, > > > > terminal2 $ vncviewer :1 -shared -AutoSelect=0 -ViewOnly=1 > > -FullColor > > > > VNC Viewer Free Edition 4.1.1 for X - built Jan 6 2007 00:46:26 > > Copyright (C) 2002-2005 RealVNC Ltd. > > See http://www.realvnc.com for information on VNC. > > > > Fri Dec 7 20:11:20 2007 > > CConn: connected to host localhost port 5901 > > > > Fri Dec 7 20:11:21 2007 > > CConnection: Server supports RFB protocol version 3.8 > > CConnection: Using RFB protocol version 3.8 > > TXImage: Using default colormap and visual, > TrueColor, depth 24. > > CConn: Using pixel format depth 24 (32bpp) > little-endian rgb888 > > CConn: Using ZRLE encoding > > > > Switch back to "terminal1", suspend the Xvnc, > > > > terminal1 $ killall -TSTP Xvnc > > > > Then switch to vncviewer x11 window, refresh screen, and > change colour > level, > > > > vncviewer x11: press F8 --> select "Refresh screen" > > vncviewer x11: press F8 --> select "Options..." --> select "Very > > low (8 colours)" in "Encoding and Colour Level:" --> click "Ok" > > > > Switch to "terminal1", resume Xvnc, > > > > terminal1 $ killall -CONT Xvnc > > > > vncviewer will then fail like this, > > > > terminal2 $ vncviewer :1 -shared -AutoSelect=0 > -ViewOnly=1 -FullColor > > <--cut--> > > ... > > <--cut--> > > CConn: Using ZRLE encoding > > > > Fri Dec 7 20:11:45 2007 > > CConn: Using pixel format depth 3 (8bpp) rgb111 > > vncviewer: ../rfb/zrleDecode.h:196: void rfb::zrleDecode8(const > > rfb::Rect&, rdr::InStream*, rdr::ZlibInStream*, rdr::U8*, > > rfb::CMsgHandler*): Assertion `len <= end - ptr' failed. > > Aborted > > > > > > > > == Cause == > > This is because the client and server fail to synchronize the pixel > > format, which is depicted as follow, > > > > server send FramebufferUpdate0 > > server is suspended > > client receive FramebufferUpdate0 > > client send FramebufferUpdateRequest1:incremental=true > > > > user request refresh screen > > client send FramebufferUpdateRequest2:incremental=false > > user change colour level > > > > server is resumed > > server receive > > FramebufferUpdateRequest1:incremental=true > > server send FramebufferUpdate1 > > client receive FramebufferUpdate1 > > client change its internal pixel format to new pixel format > > client send SetPixelFormat > > client send FramebufferUpdateRequest3:incremental=false > > (non-incremental since pixel format changed) > > client is now expecting new pixel format from server > > server receive > > FramebufferUpdateRequest2:incremental=false > > server send FramebufferUpdate2 > with old > > pixel format > > client receive FramebufferUpdate2 with old pixel format > > client interprete FramebufferUpdate2 as new pixel format > > client mis-interprete pixel format, and then fail > > > > > ---------------------------------------------------------------------- > > --- > > SF.Net email is sponsored by: > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for just about anything > > Open Source. > > http://sourceforge.net/services/buy/index.php > > _______________________________________________ > > VNC-Tight-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel > > > > --- > Peter Cstrand ThinLinc Chief Developer > Cendio AB http://www.cendio.se > Wallenbergs gata 4 > 583 30 LinkC6ping Phone: +46-13-21 46 00 > _______________________________________________ > VNC-List mailing list > VNC-List@realvnc.com > To remove yourself from the list visit: > http://www.realvnc.com/mailman/listinfo/vnc-list > _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
