Getting anti-aliasing right

[Christopher James Halse Rogers]

On Tue, 2010-11-16 at 18:30 -0800, Corbin Simpson wrote:
> 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.
> 

- Unless your compositor is transforming the buffer before scanout, at
which point your calculated antialiasing is no longer optimal.  Say
you've calculated subpixel AA with an RGB subpixel order, but the
compositor flips your buffer.  Or if the window buffer is being shrunk
the fonts might be better rendered with a different algorithm
altogether.

I think the point here is that if you treat a window containing text as
just an image you'll get less than optimal anti-aliasing under window
transformations.

This seems to be a special case of the more general observation that if
applications knew the transformations applied to their surfaces then
they could potentially perform higher quality rendering.  I don't think
the general case is feasible to accommodate, and I'd suspect that the
font-rendering case won't be significantly easier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20101117/1c3ae3c0/attachment.pgp>