In terms of providing a full scene graph to the compositor – think about scrolling in a web page – from a pixels perspective, it’s a blit, and drawing one line of text – from a scene graph perspective, it’s going to be a complete rerendering of thousands of objects moving. It’s certainly going to be a while before a pixel perspective is no longer a useful perspective – maybe in hardware of 5 years we can avoid caching to pixmaps – but certainly not in the hardware of today.

I’m actually a little skeptical that you are seeing “beating” against the refresh rate rather all sorts of other visual timing problems that can occur – yes, you could see the equivalent of “wagon wheel” beating when scrolling a web page or a terminal, but it can’t happen when moving the mouse, because mouse motion doesn’t have high frequency components that can fold back to lower frequencis – the highest frequency is the frequency at which you are wiggling the mouse.

Certainly there is a time when we’ll have suffiicient GPU power that temporaral antialiasing make sense. But even then, I don’t think it makes sense to do it in the compositor – in the limit of tons of GPU power, timing is quite predictable – you get one frame every refresh cycle – so applications can certainly do motion blur themselves.

Imagine hardware in 5-6 years, it will render real motion blur (real temporal antialiasing like in cinema, not funny fuzzy long trails after moving objects on bad monitors). Compositor know when next frame must be updated in realtime, application do not.

For now, best what we can do it at least suppress temporal aliasing noise. Example – scrolling terminal window with mouse, or even mouse pointer moving. I can see frequency beats between monitor refresh rate and application render time, it is very annoying. Recently we got compositor, so add third frequency source (monitor, compositor, application) all 3 fights berween other.

How to suppress frequency beats? Ideally – proper filter (aka motion blur).

Some approximation to motion blur:

Dithering as in color output devices ? Add small random number ( Tdisp=floor(Tapplication+0.5*(random())) of frame time, add it to actual temporal ? need test.

Anyway, we must know how long rendering take place, but in reality we cannot. It is more like TCP congestion estimators,

Motion blur would be akin to super sampling then filtering the buffered samples to a lower output rate. Sample at 60 frames per second and then filter down to 30 fps being somewhat analogous to sampling at 1200×800 and then non-nearest-neighbor filtering down to 600×400.

If you drop frames then you’re doing something more like nearest neighbor scaling and will suffer analogous artifacts. In fact, I think you’re virtually guaranteed that there is a worst-case animation for any fixed frame dropping scheme. For example, imagine if the red dot had bounced off a wall in a series of 3 frames. If your frame dropping scheme drops the middle frame then it appears as if no animation has occurred at all, or that the motion of the ball suddenly changed without hitting anything. On the other hand, if the motion is parallel to the “wall” then dropping a frame won’t be noticeable. So which frame dropping scheme you ought to choose really depends heavily on which direction the ball is moving and what its phase the frames are relative to your fixed frame dropping scheme.

Since you have “a lot” of frames per second (more than 3 ) perhaps the best way to drop frames is to add some small limited amount of jitter when selecting which frames to drop. This is just like some of the old spatial sampling schemes did when nearest-neighbor was no longer acceptable. That should get rid of the really annoying “regular” aliasing artifacts in exchange for the less noticeable irregular ones. Another drawback is you’ll see slight fluctuations in CPU/GPU load so other jitter-sensitive tasks (e.g. smoothly tracking mouse input, where latency variability is more annoying/important than low throughput) might be negatively impacted.

On the tv you can not do that so they came up with interlacing and showing each frame in two separate fields
makes you think the motion is more fluid.

This is why movies on NTSC dont look as smooth as in PAL
Because on PAL they simply run the movie faster (25fps) which makes the motion fluid but has other problems like having a different pitch (pretty bad for music)

On NTSC you simply show one frame during two fields and the next frame for 3 (12*2+12*3=60)

We could try different pulldown patterns when the app can not hit 60 so for example if it can hit 50, the compositor will have to show a frame twice every 5, for 40 every 2 and so on.

Its either that or tearing, I personally preffer stepping down to multiples of the actual display rate, in this case if an app can not hit 60 I preffer to go down to 30 then 20 and 15.
But pulldown is a valid option here. (even more with higher rate displays)

BTW owen:
http://en.wikipedia.org/wiki/Telecine
I ussually hang out at #glade3