Re: [whatwg] Enabling LCD Text and antialiasing in canvas

FYI
http://www.istartedsomething.com/20120303/cleartype-takes-a-back-seat-for-windows-8-metro/
IE 10 removed subpixel positioning and just use regular AA.

On Thu, Feb 21, 2013 at 11:12 AM, Stephen White <senorblanco@chromium.org>wrote:

> On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier@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,
> since:
>
> 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.
>
> Stephen
>
>
>>
>> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco@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.
>>>
>>>
>>> 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 Tuesday, 26 February 2013 17:03:40 UTC