GNOME Bugzilla – Bug 494059
high cpu/network usage (immediate FBUpdate replies with no changes)
Last modified: 2008-12-22 19:36:47 UTC
Please describe the problem: I'm connecting to a vino server running in the same LAN. Once i connect, my cpu load goes to 60% and network to 1-3MB/s. I ran a network sniffer and discovered that vino server responds to FBUpdateRequest immediately with FBUpdate containing update on mouse cursor, even if the mouse did not move at all. Steps to reproduce: Start a vino-server, connect to it, with both machines on a fast network (LAN). Actual results: Expected results: Does this happen every time? yes. Other information:
I heard someone else mention this problem (immediate FBUpdate replies even when nothing changed) within the last few days - definitely needs to be debugged
Wow, you guys are confusing the hell out of me - now I see that you're the same people that mentioned the problem already! (i.e. I was talking to franz and then cmeadors and then this mbabej person files a similar bug but that just turns out to be franz again ... :-)
Ah, sorry for that. I just wanted to know what does upstream developers think of this issue :) so i filed this bug.
I think I am hitting this bug as well - connections via VNC to a Gnome desktop running the vino server generate traffic all the time, even if there is no screen/mouse/keyboard activity in the Gnome desktop. This definitely does not happen with other VNC servers, i.e. if there is no screen/mouse/keyboard activity then there is no VNC traffic at all.
Attached is a patch which fixes the problem for me - could you give it some review and testing? Apparently the cursorWasMoved and cursorWasChanged flags are never reset when drawing the cursor on server-side, so that the cursor update is indeed sent as reply to every update request. Btw. the problem does not occur when using krdc as that client supports the "Cursor" pseudo encoding (-239) and the additional (TightVNC?) encodings -239 and -240 - in those cases, Vino only sends cursor position and shape. For Vinagre and xvncviewer, the cursor is drawn on server-side instead which triggers the bug.
Created attachment 125114 [details] [review] reset cursorWasChanged and cursorWasMoved after cursor is drawn
Oliver, thanks for fixing this. Would something like this work just as well? rfbDrawCursor(cl->screen, &cursorBounds); cursorIsDrawn = TRUE; + cl->cursorWasMoved = FALSE; + cl->cursorWasChanged = FALSE; cl->lastDrawnCursorBounds = cursorBounds; sraRgnOr(cl->modifiedRegion, cursorRegion);
Yes, that works as well and is much simpler :-) There's a package for Ubuntu Intrepid available at https://launchpad.net/~ogerlich/+archive , with this patch (and also the patch for bug 564520) applied.
Thanks Oliver. Patch committed: 2008-12-22 Jonh Wendell <jwendell@gnome.org> * server/libvncserver/rfbserver.c (rfbSendFramebufferUpdate): Resets cursorWasMoved and cursorWasChanged flags, thus eliminating mouse update changes, when there's no mouse change. Closes #494059. Thanks to Oliver Gerlich for the patch.