Changing pixelformat on the fly

[James Weatherall]

Peter,

> On Wed, 22 Dec 2004, James Weatherall wrote:
> 
> > Support for "local cursor rendering" is not unique to 
> TightVNC, it's a
> > feature provided as standard as part of VNC 4.
> 
> Yes, but the VNC4 implementation is different.

That doesn't affect the fact that local cursor rendering is not "unique to
TightVNC".

> > What is the relevance of the code fragment from sprite.c 
> that you refer to
> > below?
> 
> 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?

> 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.  You probably want to report this bug to Const via his
bugtracker.  So yes, this is a bug in TightVNC.

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.

Cheers,

Wez @ RealVNC Ltd.