I should have been clearer. This is like compiz, where non-transformed viewports look perfect and transformed viewports look illegible. Nobody appears to have a problem with this for compiz; why should Wayland have anything different? Sending from a mobile, pardon the brevity. ~ C. On Nov 16, 2010 7:18 PM, "Christopher James Halse Rogers" <<a href="mailto:christopher.halse.rogers@canonical.com">christopher.halse.rogers@canonical.com</a>> wrote: > On Tue, 2010-11-16 at 18:30 -0800, Corbin Simpson wrote: >> On Tue, Nov 16, 2010 at 6:14 PM, <a href="mailto:jonsmirl@gmail.com">jonsmirl@gmail.com</a> <<a href="mailto:jonsmirl@gmail.com">jonsmirl@gmail.com</a>> 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.