Getting anti-aliasing right

[Corbin Simpson]

On Tue, Nov 16, 2010 at 6:14 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> 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.

What's the difference between Wayland and X11 here, exactly? We
*already* draw anti-aliased subpixel-specific font glyphs on GPUs and
it looks fine.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>