Just a quick question, what's a ballpark reasonable tolerance for consistency in a render tickrate? For example, how delayed can a render be from the ideal time that it was supposed to be processed (due to other system activity) before it starts becoming noticeable? It's hard to get a good sense of it from staring at my game, I feel like I quickly start seeing stuff that isn't there.

In case there's concern, I'm not propagating the delays. Future frames still get processed in reference to their ideal time. Also, I'm working with 2D sprites if it makes a difference.

It depends.

In general “as fast as possible” is the goal. Also there are special circumstances that apply in many games but not in the situation you described. Competitive gaming often will take steps to get a millisecond advantage, even a sub-millisecond advantage; high frequency monitors updating at 120 Hz or even 240 Hz, disabling vsync because they'd rather have tearing rather than wait for a frame. VR hedsets want to go as fast as the displays to minimize disorientation, which can mean 72 Hz, 90 Hz, 120 Hz, 144 Hz, whatever matches, and missing it can be jarring.

But you're not in those.

For simple text, you've got about 200 ms before things get jarring.

As a generalization, regular display updates (either every refresh or every alternate refresh) is the least noticeable. But every system can have it's own refresh rate. 60 Hz is common because of old television standards and is a common, minimum standard for displays. So 60 Hz and 30 Hz follow as frequently used targets.

For many games 30 Hz or about 33 ms per frame is tolerable, on many (but not all!) displays that's every other refresh. It gets trickier with displays at different frequencies than 60 Hz, like 59 Hz or 70 Hz or 75 Hz, where a 30 Hz update isn't every other refresh but instead 2-2-3 or similar. Often the irregularity is more visible to players, not the lower rate.