[whatwg] Enabling LCD Text and antialiasing in canvas
Stephen White
senorblanco at chromium.org
Mon Mar 11 12:23:09 PDT 2013
On Mon, Mar 11, 2013 at 2:56 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> On Tue, Mar 12, 2013 at 7:53 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> All other canvas functionality behaves as normal, including operations
>> which modify the alpha values of the backing store. However, any such
>> transparency values will be ignored when compositing the canvas into the
>> page, and the canvas will be treated as if every pixel has an alpha of 1.0.
>>
>
> That would mean getImageData can return non-1.0 alpha values, which is
> probably not what you want to implement.
>
That's what Firefox/Linux does (in fact, it always seems to return 0.0
alpha from getImageData()).
I considered three options:
1) Prevent non-1.0 alpha ever getting into the canvas. At a minimum, this
would require the following:
- For putImageData, apply premultiplication, then write 1.0 alpha into
the canvas.
- Change initialization and clearRect() to clear to opaque black instead
of transparent black.
- Modify all canvas compositing modes to leave destination alpha
unchanged
The latter is easy to do in OpenGL and CoreGraphics, but hard to do in
Skia, and hard to do in accelerated CoreGraphics (IOSurfaces don't seem to
support any opaque formats, although I could be wrong -- that was just from
an hour or so of experimentation). I'm not sure about Cairo.
2) Same as (1), but force all destination-alpha-referencing compositing
modes to source-over (or raise an exception). This seems somewhat
draconian, and doesn't match what either Firefox implementation currently
does.
3) Ignore the canvas per-pixel alpha at page composite time. This seems
to be what Firefox/Linux does.
Stephen
>
> 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]
>
More information about the whatwg
mailing list