- From: Stephen White <senorblanco@chromium.org>
- Date: Thu, 14 Mar 2013 10:20:34 -0400
- To: Gregg Tavares <gman@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Mar 13, 2013 at 10:28 PM, Gregg Tavares <gman@google.com> wrote: > > > > On Wed, Mar 13, 2013 at 1:18 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> On Thu, Mar 14, 2013 at 8:04 AM, Gregg Tavares <gman@google.com> wrote: >> >>> It seems like an opaque canvas should be an orthogonal issue to >>> subpixel-aa. Subpixel AA seems like it should be a Canvas2DRenderingContext >>> setting though maybe with a name like >>> >>> ctx.antialiasingRenderQuality = >>> >>> With options of >>> >>> none >>> grayscale >>> bestForDeviceIfAxisAlignedAndNotScaledOrBlended >>> >> > My mistake. They should be > > none > alpha > > bestForDeviceIfNotCanvasIsNotRotatedAndCanvasIsNotScaledAndCanvasIsOpaque > Don't forget AndCanvasIsNotFilteredAndCanvasIsNotDrawnViaWebGLThroughAShaderWhichModifiesFragmentColour. :) (And actually, this name sort of leads me to believe the opposite: that the API will take care of these cases for me, and I don't have to worry about them.) Naming aside, this is basically the proposal from message #1 in this thread (and mine from partway through). The objections were that this is a footgun with which web developers should not be trusted. For the record, I don't agree with that assessment. However, since it seemed that moz-opaque had at least some chance of being implemented by other browser vendors, and provides a generally useful optimization, I was pursuing that approach instead. > Stephen > > ;-) > > Yes, I know that's a horrible name but it spells out the limitation of the > higher quality aa needed on some devices. A dev can opt in (Since the > default is alpha which is what happens today). > > If they opt in > > (a) it will look good if they follow the rules > > and > > (b) as the world transitions to HD-DPI it will end up being alpha so it's > forward compatible. > > > > >> Ugh! >> >> >>> This would let the developer choose. It would be clear what the limits >>> are, when to use it, and would let the developer choose what they need, >>> even in an opaque canvas. >>> >> >> Then we would need to come up with a spec for what happens when you >> composite subpixel AA over non-opaque pixels, including how the per-channel >> alpha values are combined to form a single alpha value. IIRC in some cases >> (D2D) you just can't do it. >> >> If we said that in a non-opaque canvas, subpixel AA is treated as >> grayscale, that would be OK. > > > sure. > > >> >> >> 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 Thursday, 14 March 2013 14:21:08 UTC