Try to increase the update rate by requesting a new update in parallel with
decoding the current one.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3733 3789f03b-4d11-0410-bbf8-ca57d06f2519
diff --git a/unix/vncviewer/CConn.cxx b/unix/vncviewer/CConn.cxx
index 135794a..8a9dfcf 100644
--- a/unix/vncviewer/CConn.cxx
+++ b/unix/vncviewer/CConn.cxx
@@ -300,6 +300,16 @@
}
}
+// framebufferUpdateStart() is called at the beginning of an update.
+// Here we try to send out a new framebuffer update request so that the
+// next update can be sent out in parallel with us decoding the current
+// one. We cannot do this if we're in the middle of a format change
+// though.
+void CConn::framebufferUpdateStart() {
+ if (!formatChange)
+ requestNewUpdate();
+}
+
// framebufferUpdateEnd() is called at the end of an update.
// For each rectangle, the FdInStream will have timed the speed
// of the connection, allowing us to select format and encoding
@@ -355,9 +365,19 @@
firstUpdate = false;
}
+ // A format change prevented us from sending this before the update,
+ // so make sure to send it now.
+ if (formatChange)
+ requestNewUpdate();
+
+ // Compute new settings based on updated bandwidth values
if (autoSelect)
autoSelectFormatAndEncoding();
- requestNewUpdate();
+
+ // Make sure that the X11 handling and the timers gets some CPU time
+ // in case of back to back framebuffer updates.
+ TXWindow::handleXEvents(dpy);
+ Timer::checkTimeouts();
}
// The rest of the callbacks are fairly self-explanatory...
diff --git a/unix/vncviewer/CConn.h b/unix/vncviewer/CConn.h
index 96a76fe..3bf0a82 100644
--- a/unix/vncviewer/CConn.h
+++ b/unix/vncviewer/CConn.h
@@ -81,6 +81,7 @@
void setColourMapEntries(int firstColour, int nColours, rdr::U16* rgbs);
void bell();
void serverCutText(const char* str, int len);
+ void framebufferUpdateStart();
void framebufferUpdateEnd();
void beginRect(const rfb::Rect& r, unsigned int encoding);
void endRect(const rfb::Rect& r, unsigned int encoding);