>> having the server and image renderer run on different non-synchronized clocks
Would you mind please helping me understand what this means, in detail?
I'm pretty sure there's no clock synchronisation anywhere.
Would you mind please helping me understand what this means, in detail?
I'm pretty sure there's no clock synchronisation anywhere.
That's my tired understanding, anyway.
It might be a good idea to insert a inotify immediately before the file read. You'd still need the timing code though.
f_rate = frame rate = 30 fps (for example)
f_period = 1/f_rate = 1/30 = 33ms
imagine the server serves every f_period, and the image gets updated on the ramdisk every f_period + delta where delta = f_period/16 because the clock from the image updater is not synchronized with the server and is a little slower (by some idealized fixed amount).
in this case, every 16 frames, the image updater would advance past the server, and the server would serve a duplicate frame.
in practice, delta is often not fixed, and can be positive or negative and instead is described with a distribution called jitter. both the server and the image updater have jitter, so duplicate/dropped frames will occur as they leap ahead and behind each other with the +/- jitters for each unsynchronized clock getting added to their respective periods for each frame. (this is, of course, assuming they're running at the same rate, which they often do not- which is why ultimately you want one to be the primary clock and the other to be driven by it)
In this case, for my personal needs, I'm OK with this happening - my requirement is not for highly accurate frame timing.
Other people might however, in which case your advice should be taken into accoujnt.