[client] corrected polling logic

Calculating the pollDelay for the next frame is impossible as the
frame rate is determined by the host application's capture API and
may wildly vary.
This commit is contained in:
Geoffrey McRae 2017-12-11 10:09:05 +11:00
parent ce278d17a7
commit 9f790ff51d

View File

@ -144,8 +144,6 @@ int renderThread(void * unused)
{ {
bool error = false; bool error = false;
struct KVMFRHeader header; struct KVMFRHeader header;
int pollDelay = 0;
int lateCount = 0;
volatile uint64_t * dataPos = &state.shm->dataPos; volatile uint64_t * dataPos = &state.shm->dataPos;
while(state.running) while(state.running)
@ -153,22 +151,14 @@ int renderThread(void * unused)
// if the next frame isn't aready available // if the next frame isn't aready available
if (header.dataPos == *dataPos) if (header.dataPos == *dataPos)
{ {
// wait for a frame
const uint64_t pollStart = microtime();
if (pollDelay > 0)
usleep(pollDelay);
if (header.dataPos != *dataPos)
++lateCount;
// poll until we have a new frame, or we time out // poll until we have a new frame, or we time out
while(header.dataPos == *dataPos && state.running) { while(header.dataPos == *dataPos && state.running) {
if (microtime() - pollStart > 100) const struct timespec s = {
break; .tv_sec = 0,
.tv_nsec = 1000
};
nanosleep(&s, NULL);
} }
// update the delay
pollDelay = microtime() - pollStart - 100;
} }
// we must take a copy of the header, both to let the guest advance and to // we must take a copy of the header, both to let the guest advance and to