[whatwg] Enabling LCD Text and antialiasing in canvas
cabanier at gmail.com
Fri Feb 15 08:04:08 PST 2013
On Sat, Feb 16, 2013 at 2:35 AM, Stephen White <senorblanco at chromium.org>wrote:
> On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>> On Thu, Feb 14, 2013 at 11:59 PM, Stephen White <senorblanco at chromium.org
>> > wrote:
>>> I think this is difficult to do in the general case, such as
>>> putImageData() or drawImage() or patterns, since you would need to examine
>>> all the pixels of the source image to determine if they contain non-1
>>> alpha. This would be cost-prohibitive.
>>> If it's just for the purposes of optimization, you could be conservative
>>> and simply clear the flag when there's the potential for (but not certainty
>>> of) non-1 alpha. But if you're also using that flag to allow subpixel AA,
>>> the behaviour becomes quite unpredictable for the web developer and hard to
>>> spec crisply.
>> What if we just said
>> a) non-over operators clear the subpixel AA flag
>> b) putImageData clears the subpixel AA flag
>> Both of these are infrequently used AFAIK. Authors could work around most
>> cases of b) by doing putImageData to another canvas and compositing it into
>> the destination with 'over'.
> Even with these constraints, I don't think we can guarantee that it's safe
> to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe
> at the time of drawing, there's no guarantee that it will be safe later.
> For instance, if you then drawImage() that canvas rotated into another
> canvas, or even just full-page-zoom it, you'll see colour fringing. Or
> apply CSS 2D or 3D transforms. There are also existing apps which use
> canvas for 2D text glyphs, and then transform and place them rotated in
> WebGL. Those will show colour fringing. Even within canvas, there may be a
> way to break it if the LCD AA text is drawn first and a dest-alpha
> compositing mode is used overtop (I haven't verified this though).
> So I'm starting to think that LCD AA text really has to be opt-in, to
> avoid breaking existing content. By opting it, you're agreeing that these
> artifacts are acceptable for your app. For example, you know that even if
> you're going to do a canvas-to-canvas draw, you're always going to draw at
> 1:1 scale and no rotation.
When you talk about LCD AA, do you talk about this?
If so, I don't think it would ever be safe to draw in such a way with
canvas as you can't expect an author to align canvas pixels with LCD pixels.
I assumed that we were just talking about regular pixel AA like we (=adobe)
do in our graphics products for line art.
>> How bad would that be? Would it help if we added an attribute to the
>> canvas to let authors detect whether the subpixel AA flag is set?
>> 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