3 ms·

I can see the it-adds-up argument but there are also plenty of techniques to deal with that. (Maybe it is an education issue for developers.) For instance, in

I can see the it-adds-up argument but there are also plenty of techniques to deal with that. (Maybe it is an education issue for developers.) For instance, in a lot of cases, a human cannot reasonably observe a particular type of change on every frame so you can skip frames. What I mean is, suppose you have tasks A, B, C and D to perform “each frame”: you might be able to perform tasks A and B on odd-numbered frames and C and D on even-numbered frames, with the user no wiser, as long as the result seems fine. Another technique is to prioritize the start and finish but not in-between. Often, intermediate frames are relatively crappy from a “niceness” or even correctness standpoint, and nobody really notices because the frames go by quickly. As long as the end frame looks as nice as possible and everything is in exactly the right place, you can get away with a lot of short-cuts for the steps taken to get there.

smallnamespace 10y ago
> Another technique is to prioritize the start and finish but not in-between. The problem with techniques like these is that it's almost impossible to fully generalize them (e.g. in the case of intermediate frames, if some of them are really wrong then you get sudden clipping or jumpiness). So if your 'fast' technique only works for a certain set of parameters, then you have just introduced an implicit dependency into your system: things are fast enough while the app looks like X, but go a bit beyond that and it suddenly breaks.
corysama 10y ago
In games, everything works in frames. Usually, AI, animation and physics can be completed in a single frame. But, it is very common to pipeline graphics to a separate thread that runs a frame behind everything else. The GPU frame and display frame (multiple frames on some TVs...) are pretty much impossible to eliminate. Ideally, a game would sample input multiple times per frame, go with wide parallelism for every step (very difficult for graphics until DX12/Vulkan came along), start some GPU work before physics is completed, render in less than 1/60th of a second and the users would enable no-processing "game mode" on their lag-optimized TVs. But, that's all not common practice.

smallnamespace 10y ago

> Another technique is to prioritize the start and finish but not in-between. The problem with techniques like these is that it's almost impossible to fully generalize them (e.g. in the case of intermediate frames, if some of them are really wrong then you get sudden clipping or jumpiness). So if your 'fast' technique only works for a certain set of parameters, then you have just introduced an implicit dependency into your system: things are fast enough while the app looks like X, but go a bit beyond that and it suddenly breaks.

corysama 10y ago

In games, everything works in frames. Usually, AI, animation and physics can be completed in a single frame. But, it is very common to pipeline graphics to a separate thread that runs a frame behind everything else. The GPU frame and display frame (multiple frames on some TVs...) are pretty much impossible to eliminate. Ideally, a game would sample input multiple times per frame, go with wide parallelism for every step (very difficult for graphics until DX12/Vulkan came along), start some GPU work before physics is completed, render in less than 1/60th of a second and the users would enable no-processing "game mode" on their lag-optimized TVs. But, that's all not common practice.