Changing pixelformat on the fly

[Peter Åstrand]

On Wed, 22 Dec 2004, James Weatherall wrote:

> > It shows that Xvnc from TightVNC 1.2.9 sends a cursor update 
> > as soon as it 
> > happens, without taking care to put it into the next FU. 
> 
> You wrote:
> 
> In sprite.c, we have:
> 
> pPriv->DisplayCursor = pScreen->DisplayCursor;
> ...
> pScreen->DisplayCursor = rfbDisplayCursor;
> 
> Which is the line that sends a framebuffer update?

It's in the rfbDisplayCursor function. 


> > Take a look at rfbDisplayCursor at 
> > http://cvs.sourceforge.net/viewcvs.py/vnc-tight/vnc_unixsrc/Xv
> > nc/programs/Xserver/hw/vnc/sprite.c?view=markup. 
> > As I understand it, it's incorrect to call rfbSendFramebufferUpdate()
> > directly; that would result in a FU that doesn't correspond 
> > to any FUR.
> 
> That code appears to be missing the test for the client's request region not
> being empty.  The correct test can be copied from the cursor position
> updating code.  

Ok. I must admit that I don't understand this piece of code. 


>You probably want to report this bug to Const via his
> bugtracker.  So yes, this is a bug in TightVNC.

Yes, a fix would be nice, but as I said, we'll need to deal with "buggy" 
1.2.9 servers anyway. So, my plan is to disable pixel formats change on 
the fly, if the RFB version is <= 3.7. 


> Out of interest, why do you want to decrease the colour depth for slow
> connections?  You'll never get into a state where the connection is in
> full colour mode in the first place, if the connection is slow, unless
> you've explicitly overridden the AutoSelect defaults.

The bandwidth can change dynamically during a session. Also, the current
TightVNC vncviewer4 starts off in fullcolor mode, unlike the RealVNC 4.0
version.


-- 
Peter Estrand		Chief Developer
Cendio			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linkvping        Phone: +46-13-21 46 00