Changing pixelformat on the fly
jnw "at" realvnc.com
Wed Dec 22 15:13:01 2004
Support for "local cursor rendering" is not unique to TightVNC, it's a
feature provided as standard as part of VNC 4.
What is the relevance of the code fragment from sprite.c that you refer to
There's no reason why fixing the cursor updating bug in TightVNC should have
affected sending of updates in any way - a cursor update is just a
particular special case of a normal framebuffer update. Can you provide a
link to the code in TightVNC 1.2.9 that you think is at fault?
It is *much* more likely that you have broken your "modified" viewer in some
way. Can you provide a patch file containing all the diffs between your
modified viewer and the standard one?
Wez @ RealVNC Ltd.
> > The most likely cause of the problem is that whatever
> modification of the
> > VNC Viewer you have made violates the protocol semantics.
> I've done some further investigations now, and I still think
> the server is
> wrong: Occasionally, the TightVNC 1.2.9 Xvnc does send an
> unsolicited FU.
> It doesn't come from "deferred updates", though, but from the cursor
> update routine rfbDisplayCursor. In sprite.c, we have:
> pPriv->DisplayCursor = pScreen->DisplayCursor;
> pScreen->DisplayCursor = rfbDisplayCursor;
> So, from what I can tell from my debug printouts[*],
> occasionally, two FUs
> are sent as a response to one FUR: First the "real" FU is sent, then,
> asynchroniously (I guess), a FU with a new cursor is sent.
> The rfbDisplayCursor stuff is unique to TightVNC. It seems like this
> problem was introduced during the fix for bug 726935
> [*]Wouldn't it be nice with a VNC protocol analyzer?
> Something like an
> Ethereal dissector, or a VNC-version of rdpproxy/pparser...
> Peter Estrand Chief Developer
> Cendio www.thinlinc.com
> Teknikringen 3 www.cendio.se
> 583 30 Linkvping Phone: +46-13-21 46 00
> VNC-List mailing list
> VNC-List "at" realvnc.com
> To remove yourself from the list visit: