I'm not sure if this is much of an answer, but...
Roughly speaking, if you are finished the work and want to render it, then that happens on a set schedule. Your graphics (WebGL) calls buffer things to be done; on next vsync (typically, in a browser environment), those commands should all have reached the GPU so they can be effected.
You really want to ensure that gap is always reasonably sized, because if you are still buffering commands when the next vsync comes around, your display may show odd results (depends very much on your implementation specifics). Other than that, you don't have to worry about the gap as such since your buffered commands that have been sent to the GPU will simply be put into practice at the next scheduled vsync.
If you want to be very sure you are not still making commands across the system bus when the threshold (~16.7ms @ 60fps) is reached, just make sure your ticks always take way less than 16.7 milliseconds (depending how close you want to cut it). You could have a cut-off at say 15ms in. If you're doing this on e.g. RequestAnimationFrame
, then you have that much time to get all your work done, and a 1.7ms safety buffer (but you need to test to be sure of what works for you). If the job doesn't look complete by that point, just don't schedule draw calls for it till next frame (or later frames, even). You should only be doing draw calls for data that is in a ready state.
TL;DR Ensure your processing and resultant draw calls complete well before the render period does, and you will be fine. Profiling your code is the best way to determine if that is the case.