- From: Stephen White <senorblanco@chromium.org>
- Date: Fri, 8 Mar 2013 18:57:02 -0500
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>
On Sat, Feb 23, 2013 at 6:48 AM, Robert O'Callahan <robert@ocallahan.org>wrote: > 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. > Given that that's the case, I am going to move forward with the opaque attribute, since I feel it is the lesser of all the evils presented thus far. Paying the cost of two buffers and double-rendering just isn't palatable, IMHO. > 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. > We also might be over-thinking the danger that LCD AA poses. Firefox/Linux and Firefox/Mac are both currently shipping with LCD AA turned on unconditionally in <canvas>, and it's trivial to make them expose color fringing. WebKit nightlies (Safari build) seem do the same, although Safari 6.0 doesn't. Stephen > 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 Friday, 8 March 2013 23:57:30 UTC