[whatwg] Enabling LCD Text and antialiasing in canvas
cabanier at gmail.com
Tue Feb 26 09:03:13 PST 2013
IE 10 removed subpixel positioning and just use regular AA.
On Thu, Feb 21, 2013 at 11:12 AM, Stephen White <senorblanco at chromium.org>wrote:
> On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>> So now we have:
>> - don't do this on pinch-zoom devices
>> - don't do this for HW accelerated canvases
>> - don't do this if the canvas dpi doesn't match the screen
> - don't do this if there are transforms
>> - authors will have to be very careful when using this feature since it
>> can turn on or off or cause rendering glitches.
>> Is it still worth pursuing this?
> I believe it is. Even with those constraints, there are a large number of
> applications which can benefit from text which looks as good as the native
> platform can provide.
> That said, I also think Robert is right that we should not spec out
> precisely when subpixel AA text will occur in any of these automatic modes,
> 1) there are some platforms/devices which don't do LCD text at all
> 2) It may be too restrictive for the browser implementor, e.g., they may
> be essentially required to implement deferred rendering or two backing
> stores in order to meet the resulting spec, which seems onerous
> Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque,
> if only just for the optimization opportunities that we don't get with an
> automatic solution (e.g., putImageData). Its implementation is fairly
> straightforward (much more so than the other options above), and it won't
> break any existing content.
> To me, the "it breaks compositing" argument falls into the "doctor, it
> hurts when I do this" category: the user is specifically opting into an
> opaque backing store, and so the changes in behaviour for compositing modes
> which reference destination alpha are expected, just as they are when using
> DST_ALPHA blending modes in a WebGL context created with the "alpha"
> attribute set to false.
>> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org
>>> > wrote:
>>>> Even with text on an opaque background, I think you still have to worry
>>>> about the case of transformed canvases. E.g., text drawn over an opaque
>>>> background into a single still frame canvas, but then subsequently rotated
>>>> via CSS transforms from 0 degrees through non-0. The first frame can use
>>>> subpixel AA, but then subsequent frames can't. So I think you need to keep
>>>> the command stream around (first case) or
>>>> always render two buffers as soon as you draw text. That seems like a
>>>> pretty heavy burden.
>>>> For canvas->WebGL the problem becomes pretty much intractable, since
>>>> there's no way to know what a given shader will do to the pixels. So I
>>>> think you'd always have to give up and do grayscale AA in that case.
>>> Yes, you're quite right.
>>> 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]
More information about the whatwg