Getting anti-aliasing right

[jonsmirl at gmail.com]

What is the plan for anti-aliasing? If an app draws a beautiful
anti-aliased scene to a buffer, and then that buffer is transformed by
the compositor, all of that beautiful anti-aliasing is going to get
messed up. Especially sub-pixel antialiasing if the compositor
transform changes the alignment of the screen with the LCD pixels.

One approach is to tell the app the final window transform and let
them draw a transformed screen instead of a rectangle that gets
transformed by the compositor. But this means an app need to be able
to handle being told to project itself onto a rotating sphere.

Another approach is for apps to create a screen graph out of
primitives that some other system renders when it know the final
transform. This method lets the compositor implement animations
without involving the app.

This problem is closely tied into glyph generation. Sooner or later
we're going to be generating glyphs on the GPU in real-time. If we're
doing that then you don't want anti-aliased glyphs being generated
inside the apps like we do today. Apps will still need to compute
glyph spacing and pick a spacing as a result of hinting, but the
compositor may want to regenerate the glyphs if the window is shrunk,
zoomed, twisted, etc.

I'm sure there are other ways to handle anti-aliasing. If the goal is
to make pixel perfect images every time then anti-aliasing strategy is
something that needs to be planned.

-- 
Jon Smirl
jonsmirl at gmail.com