- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Sun, 24 Feb 2013 00:48:45 +1300
- To: Stephen White <senorblanco@chromium.org>
- Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>
On Sat, Feb 23, 2013 at 4:59 AM, Stephen White <senorblanco@chromium.org>wrote: > On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert@ocallahan.org >> > wrote: >> >>> I think a fully automatic solution that tries to use subpixel AA but is >>> always able to render grayscale AA if needed is the way to go. Possibly >>> with an author hint to suggest opting into a more expensive rendering path. >> >> > Here are the problems I see with that approach: > > 1) In order to avoid a performance hit for existing content, it still > requires a spec change (the hint) > 2) Even with the hint, when the author knows they want LCD AA, they still > incur a performance penalty of drawing to two buffers. > 3) It still can't handle all cases, such as canvas -> WebGL, which will > have to remain grayscale-only, even when the author knows it would be safe > for their application. > I agree those are problems. All of the available options have problems. Also, what form should this authoring hint take? Is it going to explicitly > call out LCD AA? In that case, how is it better than an opt-in canvas > attribute? If it doesn't explicitly call out LCD AA, but that's the only > effect it has, what should it be called? > Perhaps we could use "text-rendering:optimizeLegibility" on the canvas element. I also have concerns that the knowledge of when it's safe to use the LCD AA > buffer is going to spread throughout the browser codebase, even in areas > which currently have no knowledge of canvas, in order to handle all the > special cases. This may just be an implementation detail (and may be > avoidable, this is TBD), but it does have the potential to introduce > dependencies or complicate implementation. > Maybe. Maybe I'm missing something, but if we're going down the automatic road, > why do we need a new function/attribute? Why not simply detect when a > canvas-sized fillRect() has been performed with an opaque fillStyle? This > would also allow optimization of existing content. I agree. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Received on Saturday, 23 February 2013 11:49:15 UTC