Changing pixelformat on the fly
astrand "at" cendio.se
Wed Dec 22 16:15:01 2004
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
Peter Estrand Chief Developer
Teknikringen 3 www.cendio.se
583 30 Linkvping Phone: +46-13-21 46 00