Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Jul 16, 2013 at 6:41 PM, Ian Hickson i...@hixie.ch wrote:
This thread was gigantic and involved many proposals. I've only included
the last one below, since it seemed to take into account the most of the
feedback mentioned on the thread; I haven't responded to all the
intermediate e-mails which were mainly just a discussion amongst
contributors, and not direct feedback on the spec itself.
I haven't yet changed the spec. The main thrust of the feedback below ends
with the proposal to use WebGL's 'alpha' feature for the 2D context; is
this what implementors want to do?
We're implementing this in Chromium (currently behind the experimental
canvas features flag).
[...]
On Fri, 15 Feb 2013, Stephen White wrote (with roc's annotations inline
prefixed with | and mine inline not prefixed):
So let me take a stab at a brief summary of the proposals so far, and
the pros and cons of each (correct me if I missed anything):
opaque attribute or matteColor property
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
| con: requires changes to canvas compositing spec and possibly
| implementations.
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL,
etc
context.textAntialising = { 'none', 'grayscale', 'subpixel' }
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
| con: requires specification and implementation of what happens when
| subpixel AA is drawn over transparent background.
collect commands into a buffer, flush buffer only when compositing
canvas to page, and decide on subpixel AA at that point.
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that
never clears, and only accumulates drawing frame-to-frame means
you must accumulate commands indefinitely)
or giving up and using grayscale at some point
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone
without)
con: doesn't handle pixel manipulation cases (since you can't return
two sets of pixels and you can't regenerate the stuff that script
is generating based on the returned pixels)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or VRAM) usage is doubled
con: possibly-unnecessary performance hit
con: must be opt-in
[...]
On Wed, 20 Feb 2013, Rik Cabanier 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?
On Thu, 21 Feb 2013, Stephen White wrote:
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.
On Fri, 22 Feb 2013, Robert O'Callahan wrote:
I think Rik is convincing me that we shouldn't
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
This thread was gigantic and involved many proposals. I've only included
the last one below, since it seemed to take into account the most of the
feedback mentioned on the thread; I haven't responded to all the
intermediate e-mails which were mainly just a discussion amongst
contributors, and not direct feedback on the spec itself.
I haven't yet changed the spec. The main thrust of the feedback below ends
with the proposal to use WebGL's 'alpha' feature for the 2D context; is
this what implementors want to do?
[...]
On Fri, 15 Feb 2013, Stephen White wrote (with roc's annotations inline
prefixed with | and mine inline not prefixed):
So let me take a stab at a brief summary of the proposals so far, and
the pros and cons of each (correct me if I missed anything):
opaque attribute or matteColor property
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
| con: requires changes to canvas compositing spec and possibly
| implementations.
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL,
etc
context.textAntialising = { 'none', 'grayscale', 'subpixel' }
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
| con: requires specification and implementation of what happens when
| subpixel AA is drawn over transparent background.
collect commands into a buffer, flush buffer only when compositing
canvas to page, and decide on subpixel AA at that point.
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that
never clears, and only accumulates drawing frame-to-frame means
you must accumulate commands indefinitely)
or giving up and using grayscale at some point
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone
without)
con: doesn't handle pixel manipulation cases (since you can't return
two sets of pixels and you can't regenerate the stuff that script
is generating based on the returned pixels)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or VRAM) usage is doubled
con: possibly-unnecessary performance hit
con: must be opt-in
[...]
On Wed, 20 Feb 2013, Rik Cabanier 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?
On Thu, 21 Feb 2013, Stephen White wrote:
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.
On Fri, 22 Feb 2013, Robert O'Callahan wrote:
I think Rik is convincing me that we shouldn't expose mozOpaque or any
other explicit subpixel AA control to the Web. It will be very easy for
Web authors to test it in one place and discover that it works without
realizing that they're causing problems for some
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, 24 Nov 2012, Adam Barth wrote: On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. The metrics I've seen show that the magnitude of this problem is approximately 8x (to the extent that it's sensible to represent the magnitude with a number). As far as I can tell, the issue really boils down to the DOM being retained mode and canvas being immediate mode. [...snip a very lucid explanation of why some people end up using canvas when they are writing an app that has a large underlying model, even if their output has little to do with graphics per se] I think the real question here is how do we want applications with very large models to render? Do we really want them to upload their entire models into DOM? If not, how can we provide them with a high-quality immediate model rendering pipeline. I don't think the DOM and a bitmap API are the only points on the spectrum that we should discuss here. Using canvas (2D or GL) to generate a traditional app (i.e. not a game) is a disaster. Here's a brief list of the ways doing this would suck: Platform-native look and feel of widgets has to be reimplemented. Platform-native accessibility bindings have to be reimplemented. Platform-native scrolling behaviour of scroll areas have to be reimplemented. Mouse placement of text carets has to be reimplemented. Keyboard movement of text carets has to be reimplemented (possibly across lines, for multiline text input). Scrolling of text fields has to be implemented (horizontally for long lines, vertically for multiline input). Native features such as copy-and-paste have to be reimplemented. Native features such as spell-checking have to be reimplemented. Native features such as drag-and-drop have to be reimplemented. Native features such as page-wide text search have to be reimplemented. Native features specific to the user, for example custom text services, have to be reimplemented. This is close to impossible since each user might have different services installed, and there is an unbounded set of possible such services. Bidirectional text editing has to be reimplemented. For multiline text editing, line wrapping has to be implemented for all relevant languages. Text selection has to be reimplemented. Dragging of bidirectional text selections has to be reimplemented. Platform-native keyboard shortcuts have to be reimplemented. Platform-native input method editors (IMEs) have to be reimplemented. Undo and redo functionality has to be reimplemented. Accessibility features such as magnification following the caret or selection have to be reimplemented. IMHO we should provide an API that addresses these needs while providing the performance of a non-DOM-backed immediate-ish mode API. It's not canvas. I'm not sure what it is, exactly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Nice!
The behaviour of putImageData() and putImageDataHD() is to premultiply the
RGB components by the alpha component as usual, but write 1.0 into
destination alpha. In other words, if (r, g, b, a) are the component values
in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' =
ab are the colour components of the resulting canvas pixel, and (r', g',
b', 1.0) is written to the canvas backing store.
I think that's confusing. Maybe cut that sentence since it isn't needed.
(Having the black backing store implies this behavior)
attribute boolean alpha;
Should it be read-only?
Canvas2DContextAttributes getContextAttributes();
Maybe make it an attribute:
attribute Canvas2DContextAttributes attributes:
On Fri, Apr 19, 2013 at 9:13 AM, Stephen White senorbla...@chromium.orgwrote:
Here's a short proposal I've written up for the getContext('2d', { alpha:
false } ) version of this idea (much of it culled from the mega-thread
above).
http://wiki.whatwg.org/wiki/CanvasOpaque
Comments are welcome.
Stephen
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Thanks for your comments.
On Fri, Apr 19, 2013 at 12:53 PM, Rik Cabanier caban...@gmail.com wrote:
Nice!
The behaviour of putImageData() and putImageDataHD() is to premultiply the
RGB components by the alpha component as usual, but write 1.0 into
destination alpha. In other words, if (r, g, b, a) are the component values
in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' =
ab are the colour components of the resulting canvas pixel, and (r', g',
b', 1.0) is written to the canvas backing store.
I think that's confusing. Maybe cut that sentence since it isn't needed.
(Having the black backing store implies this behavior)
Do you mean, remove both sentences, or just the last one? I wanted to make
it clear that the RGB is still premultiplied with the original alpha, even
though the alpha is subsequently ignored.
attribute boolean alpha;
Should it be read-only?
Hmm, I have no idea. WebGL's doesn't have it, but I'm not enough of an IDL
expert to know whether it's necessary.
Canvas2DContextAttributes getContextAttributes();
Maybe make it an attribute:
attribute Canvas2DContextAttributes attributes:
I'm following WebGL syntax here as well. Apparently WebGL's is nullable,
though, so I've added ? here.
Stephen
On Fri, Apr 19, 2013 at 9:13 AM, Stephen White
senorbla...@chromium.orgwrote:
Here's a short proposal I've written up for the getContext('2d', { alpha:
false } ) version of this idea (much of it culled from the mega-thread
above).
http://wiki.whatwg.org/wiki/CanvasOpaque
Comments are welcome.
Stephen
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Apr 20, 2013 at 4:13 AM, Stephen White senorbla...@chromium.orgwrote:
Here's a short proposal I've written up for the getContext('2d', { alpha:
false } ) version of this idea (much of it culled from the mega-thread
above).
http://wiki.whatwg.org/wiki/CanvasOpaque
Looks reasonable to me.
Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Would Mozilla (or other browser vendors) be interested in implementing the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart from LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a syntactic
rewrite of canvas opaque). Does this indeed have traction with other
browser vendors?
As for naming, I would prefer that it be something like ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call out
subpixel antialiasing, even if the platform (or UA) does not support it,
especially if the attribute explicitly describes itself as a hint.
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com wrote:
Let me ask again in a different way ;-) Specifically about LCD style
antialiasing.
What about a context attribute antialiasRenderingQualityHint for now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author uses
displayDependent and then draws text over transparent pixels in the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec doesn't say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without this
hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
Very few developers are going to run into issues. Most developers that use
canvas aren't going to set the hint. Most developers that use canvas dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the hint
they'll get probably get some fringing but there (a) there was no guarantee
they wouldn't already have that problem since as pointed out, the spec
doesn't specify AA nor what kind, and (b) if they care they'll either stop
using the hint or they'll search for why is my canvas fringy and the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White senorbla...@chromium.orgwrote:
Would Mozilla (or other browser vendors) be interested in implementing the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart from LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a syntactic
rewrite of canvas opaque). Does this indeed have traction with other
browser vendors?
As for naming, I would prefer that it be something like ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call out
subpixel antialiasing, even if the platform (or UA) does not support it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render paths
using the same hint?
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com wrote:
Let me ask again in a different way ;-) Specifically about LCD style
antialiasing.
What about a context attribute antialiasRenderingQualityHint for now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author uses
displayDependent and then draws text over transparent pixels in the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without this
hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
Very few developers are going to run into issues. Most developers that use
canvas aren't going to set the hint. Most developers that use canvas dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed out, the spec
doesn't specify AA nor what kind, and (b) if they care they'll either stop
using the hint or they'll search for why is my canvas fringy and the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White senorbla...@chromium.org
wrote:
Would Mozilla (or other browser vendors) be interested in implementing
the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart from
LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a syntactic
rewrite of canvas opaque). Does this indeed have traction with other
browser vendors?
As for naming, I would prefer that it be something like ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS
property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call out
subpixel antialiasing, even if the platform (or UA) does not support it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render paths
using the same hint?
I have not heard of anyone using sub-pixel antialiasing for vector art. It
might look weird...
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan
rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com
wrote:
Let me ask again in a different way ;-) Specifically about LCD style
antialiasing.
What about a context attribute antialiasRenderingQualityHint for
now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author uses
displayDependent and then draws text over transparent pixels in the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the
canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without
this
hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
Very few developers are going to run into issues. Most developers that
use
canvas aren't going to set the hint. Most developers that use canvas
dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed out, the spec
doesn't specify AA nor what kind, and (b) if they care they'll either
stop
using the hint or they'll search for why is my canvas fringy and the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 5:04 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White senorbla...@chromium.org
wrote:
Would Mozilla (or other browser vendors) be interested in implementing
the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart from
LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a syntactic
rewrite of canvas opaque). Does this indeed have traction with other
browser vendors?
As for naming, I would prefer that it be something like
ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS
property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call
out
subpixel antialiasing, even if the platform (or UA) does not support it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render paths
using the same hint?
I have not heard of anyone using sub-pixel antialiasing for vector art. It
might look weird...
??? Fonts are vector art. Why should this flag be specific to fonts? So I
decide tomorrow that I want vector art to be prettier than the competition
in by implementing LCD anti-aliasing I'll have to lobby for a new flag to
turn it on? Why?
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com
wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan
rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com
wrote:
Let me ask again in a different way ;-) Specifically about LCD
style
antialiasing.
What about a context attribute antialiasRenderingQualityHint for
now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author uses
displayDependent and then draws text over transparent pixels in the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the
canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without
this
hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
Very few developers are going to run into issues. Most developers that
use
canvas aren't going to set the hint. Most developers that use canvas
dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed out, the spec
doesn't specify AA nor what kind, and (b) if they care they'll either
stop
using the hint or they'll search for why is my canvas fringy and the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Fonts are not vector art and are not rendered as paths at commonly read
sizes. I don't think anyone is using or would be tempted to use LCD
subpixel AA for anything other than text.
- James
On Wed, Apr 3, 2013 at 5:07 PM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 5:04 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White senorbla...@chromium.org
wrote:
Would Mozilla (or other browser vendors) be interested in implementing
the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart
from
LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a
syntactic
rewrite of canvas opaque). Does this indeed have traction with other
browser vendors?
As for naming, I would prefer that it be something like
ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS
property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call
out
subpixel antialiasing, even if the platform (or UA) does not support
it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render
paths
using the same hint?
I have not heard of anyone using sub-pixel antialiasing for vector art.
It
might look weird...
??? Fonts are vector art. Why should this flag be specific to fonts? So I
decide tomorrow that I want vector art to be prettier than the competition
in by implementing LCD anti-aliasing I'll have to lobby for a new flag to
turn it on? Why?
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com
wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan
rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com
wrote:
Let me ask again in a different way ;-) Specifically about LCD
style
antialiasing.
What about a context attribute antialiasRenderingQualityHint for
now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author
uses
displayDependent and then draws text over transparent pixels in the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec
doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the
canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without
this
hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
Very few developers are going to run into issues. Most developers
that
use
canvas aren't going to set the hint. Most developers that use canvas
dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the
hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed out, the
spec
doesn't specify AA nor what kind, and (b) if they care they'll either
stop
using the hint or they'll search for why is my canvas fringy and
the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 5:09 PM, James Robinson jam...@google.com wrote:
Fonts are not vector art
O RLY? So you're saying the following 250pt ampersand is stored as a
bitmap in the font file?
and are not rendered as paths at commonly read sizes. I don't think
anyone is using or would be tempted to use LCD subpixel AA for anything
other than text.
I think google docs, as one example, would be happy to have graphs in
spreadsheets and drawings looks a beautiful as possible.
Why do you think the AA hint should be overly specific? I don't see the
downside.
- James
On Wed, Apr 3, 2013 at 5:07 PM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 5:04 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White
senorbla...@chromium.org
wrote:
Would Mozilla (or other browser vendors) be interested in
implementing
the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart
from
LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a
syntactic
rewrite of canvas opaque). Does this indeed have traction with
other
browser vendors?
As for naming, I would prefer that it be something like
ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS
property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call
out
subpixel antialiasing, even if the platform (or UA) does not support
it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render
paths
using the same hint?
I have not heard of anyone using sub-pixel antialiasing for vector art.
It
might look weird...
??? Fonts are vector art. Why should this flag be specific to fonts? So
I
decide tomorrow that I want vector art to be prettier than the competition
in by implementing LCD anti-aliasing I'll have to lobby for a new flag to
turn it on? Why?
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com
wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan
rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com
wrote:
Let me ask again in a different way ;-) Specifically about LCD
style
antialiasing.
What about a context attribute antialiasRenderingQualityHint
for
now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author
uses
displayDependent and then draws text over transparent pixels in
the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec
doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the
canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without
this
hint the spec doesn't prevent a UA from unconditionally using
LCD-AA.
Very few developers are going to run into issues. Most developers
that
use
canvas aren't going to set the hint. Most developers that use canvas
dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the
hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed out, the
spec
doesn't specify AA nor what kind, and (b) if they care they'll
either
stop
using the hint or they'll search for why is my canvas fringy and
the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 12:04 PM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White senorbla...@chromium.orgwrote:
Would Mozilla (or other browser vendors) be interested in implementing
the hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity, and
consider the latter on its own merits, since it has benefits apart from LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a syntactic
rewrite of canvas opaque). Does this indeed have traction with other
browser vendors?
As for naming, I would prefer that it be something like ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly call out
subpixel antialiasing, even if the platform (or UA) does not support it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render paths
using the same hint?
I think it would be better to control antialiasing for fonts and paths
independently. In addition to providing greater control, subpixel
antialiasing usually only benefits small, detailed paths such as fonts.
Large paths don't benefit greatly from it.
On a practical level, most platform graphics APIs don't provide subpixel
antialiasing for paths, only for text. So it would have to be implemented
as a custom path renderer, and it would have to have access to the LCD
subpixel structure and orientation, which many platform APIs may not
provide.
Stephen
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com
wrote:
Let me ask again in a different way ;-) Specifically about LCD style
antialiasing.
What about a context attribute antialiasRenderingQualityHint for now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author uses
displayDependent and then draws text over transparent pixels in the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas is
composited on white. If they want some other color they'd fill the canvas
with as solid color first. Personally I don't think that needs to be
specced, but it would be my suggestion. As I mentioned, even without this
hint the spec doesn't prevent a UA from unconditionally using LCD-AA.
Very few developers are going to run into issues. Most developers that
use
canvas aren't going to set the hint. Most developers that use canvas
dont'
make it transparent nor do they CSS rotate/scale them. For those few
developers that do happen to blend and/or rotate/scale AND set the hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed out, the spec
doesn't specify AA nor what kind, and (b) if they care they'll either
stop
using the hint or they'll search for why is my canvas fringy and the
answer will pop up on stackoverlow and they can choose one of the
solutions.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 5:09 PM, James Robinson jam...@google.com wrote:
Fonts are not vector art
O RLY? So you're saying the following 250pt ampersand is stored as a
bitmap in the font file?
It's not simply stored as a path that you then scale. In some fonts it
might be in a completely different format than a path (or it could even be
a bitmap)
and are not rendered as paths at commonly read sizes. I don't think
anyone is using or would be tempted to use LCD subpixel AA for anything
other than text.
I think google docs, as one example, would be happy to have graphs in
spreadsheets and drawings looks a beautiful as possible.
Why do you think the AA hint should be overly specific? I don't see the
downside.
Fonts render different from paths. If your UA doesn't do that, you are
doing it wrong. :-)
Line art looks different to the human eye than a line of text. Imagina a
vertical and a horizontal line rendered with sub-pixel AA; they will look
very different.
Text also has the nice property that it's filled with a solid color. If you
do subpixel AA on a gradient, the edge will change position which is very
wrong.
On Wed, Apr 3, 2013 at 5:07 PM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 5:04 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares g...@google.com wrote:
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White
senorbla...@chromium.org
wrote:
Would Mozilla (or other browser vendors) be interested in
implementing
the
hint as Gregg described above?
If so, we could break out the LCD text issue from canvas opacity,
and
consider the latter on its own merits, since it has benefits apart
from
LCD
text (i.e., performance). Regarding that, if I'm reading correctly,
Vladimir Vukicevic has expressed support on webkit-dev for the
ctx.getContext('2d', { alpha: false }) proposal (basically, a
syntactic
rewrite of canvas opaque). Does this indeed have traction with
other
browser vendors?
As for naming, I would prefer that it be something like
ctx.fontSmoothing
or ctx.fontSmoothingHint, to align more closely with canvas's
ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS
property.
-webkit-font-smoothing has none, antialiased and
subpixel-antialiased as options. I think it's ok to explicitly
call
out
subpixel antialiasing, even if the platform (or UA) does not
support it,
especially if the attribute explicitly describes itself as a hint.
Why call it Font smoothing? Shouldn't a UA be able to also render
paths
using the same hint?
I have not heard of anyone using sub-pixel antialiasing for vector
art. It
might look weird...
??? Fonts are vector art. Why should this flag be specific to fonts?
So I
decide tomorrow that I want vector art to be prettier than the
competition
in by implementing LCD anti-aliasing I'll have to lobby for a new flag to
turn it on? Why?
Stephen
On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares g...@google.com
wrote:
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan
rob...@ocallahan.org
wrote:
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com
wrote:
Let me ask again in a different way ;-) Specifically about LCD
style
antialiasing.
What about a context attribute antialiasRenderingQualityHint
for
now
with
2 settings default and displayDependent
context.antialiasRenderingQualityHint = displayDependent
How would this interact with canvas opacity? E.g. if the author
uses
displayDependent and then draws text over transparent pixels in
the
canvas,
what is the UA supposed to do?
Whatever the UA wants. It's a hint. From my POV, since the spec
doesn't
say
anything about anti-aliasing then it really doesn't matter.
My preference, if I was programming a UA, would be if the user sets
displayDependent and the UA is running on a lo-dpi machine I'd
unconditionally render LCD-AA with the assumption that the canvas
is
composited on white. If they want some other color they'd fill the
canvas
with as solid color first. Personally I don't think that needs to
be
specced, but it would be my suggestion. As I mentioned, even
without
this
hint the spec doesn't prevent a UA from unconditionally using
LCD-AA.
Very few developers are going to run into issues. Most developers
that
use
canvas aren't going to set the hint. Most developers that use
canvas
dont'
make it transparent nor do they CSS rotate/scale them. For those
few
developers that do happen to blend and/or rotate/scale AND set the
hint
they'll get probably get some fringing but there (a) there was no
guarantee
they wouldn't already have that problem since as pointed
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/04/04 10:08, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares g...@google.com wrote: O RLY? So you're saying the following 250pt ampersand is stored as a bitmap in the font file? It's not simply stored as a path that you then scale. In some fonts it might be in a completely different format than a path (or it could even be a bitmap) As screen pixel densities soar, it is increasingly the case that fonts are stored simply as paths that are scaled, especially fonts which have thousands of characters. Fonts render different from paths. If your UA doesn't do that, you are doing it wrong. :-) Line art looks different to the human eye than a line of text. Imagina a vertical and a horizontal line rendered with sub-pixel AA; they will look very different. Vertical and horizontal lines won't have any aliasing to begin with so what are you talking about? Text also has the nice property that it's filled with a solid color. I know little about Canvas2D but I do know that PostScript and SVG both support gradients etc. when filling text so your statement is wrong. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/04/04 10:08, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares g...@google.com wrote: Fonts render different from paths. If your UA doesn't do that, you are doing it wrong. :-) Line art looks different to the human eye than a line of text. Imagina a vertical and a horizontal line rendered with sub-pixel AA; they will look very different. There are systems that use sub-pixel AA for everything and don't seem to suffer because of it. The Haiku OS https://www.haiku-os.org/blog/andrej_spielmann/2008-07-23/sub_pixel_antialiasing_report_2_gsoc for example. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/04/04 13:50, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 9:25 PM, Mark Callow callow.m...@artspark.co.jp mailto:callow.m...@artspark.co.jp wrote: As screen pixel densities soar, it is increasingly the case that fonts are stored simply as paths that are scaled, especially fonts which have thousands of characters. No, that is not true. Talk to font vendors; fonts are not just a collection of path segments. They are also not rendered as paths; instead they should have specific renderers. The people who work on our HiGlyph library tell me it is changing. I have no references I can provide. Vertical and horizontal lines won't have any aliasing to begin with so what are you talking about? Of course they have aliasing. Why wouldn't they? Because they are vertical and horizontal, therefore no jaggies (aliasing). Text also has the nice property that it's filled with a solid color. I know little about Canvas2D but I do know that PostScript and SVG both support gradients etc. when filling text so your statement is wrong. I worked on the rendering engine of Illustrator and Acrobat for 11 years. Subpixel AA is disabled for text that is filled with gradients or images and reverts to normal rendering. AFAIK there is no postscript implementation that supports subpixel positioning. Can you point me to a spec where you can fill text in canvas with a gradient instead of a solid color? As I wrote, I don't know much about Canvas2D. Besides it wasn't clear that your comment referred only to Canvas2D. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Apr 3, 2013 at 10:02 PM, Mark Callow callow.m...@artspark.co.jpwrote: On 2013/04/04 13:50, Rik Cabanier wrote: On Wed, Apr 3, 2013 at 9:25 PM, Mark Callow callow.m...@artspark.co.jpwrote: As screen pixel densities soar, it is increasingly the case that fonts are stored simply as paths that are scaled, especially fonts which have thousands of characters. No, that is not true. Talk to font vendors; fonts are not just a collection of path segments. They are also not rendered as paths; instead they should have specific renderers. The people who work on our HiGlyph library tell me it is changing. I have no references I can provide. If there are new fonts that are simple shapes, you'd still have to deal with all the old fonts that are not like that. Vertical and horizontal lines won't have any aliasing to begin with so what are you talking about? Of course they have aliasing. Why wouldn't they? Because they are vertical and horizontal, therefore no jaggies (aliasing). Subpixel AA is a trick to increase resolution. In this case, a line that is more than 1 device pixel would have grayscale in all directions with regular AA, but only colors in x and y for subpixel AA. Text also has the nice property that it's filled with a solid color. I know little about Canvas2D but I do know that PostScript and SVG both support gradients etc. when filling text so your statement is wrong. I worked on the rendering engine of Illustrator and Acrobat for 11 years. Subpixel AA is disabled for text that is filled with gradients or images and reverts to normal rendering. AFAIK there is no postscript implementation that supports subpixel positioning. Can you point me to a spec where you can fill text in canvas with a gradient instead of a solid color? As I wrote, I don't know much about Canvas2D. Besides it wasn't clear that your comment referred only to Canvas2D. This is a discussion on adding parameters to Canvas2D. Maybe that got lost in the thread :-)
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com wrote: Let me ask again in a different way ;-) Specifically about LCD style antialiasing. What about a context attribute antialiasRenderingQualityHint for now with 2 settings default and displayDependent context.antialiasRenderingQualityHint = displayDependent How would this interact with canvas opacity? E.g. if the author uses displayDependent and then draws text over transparent pixels in the canvas, what is the UA supposed to do? 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares g...@google.com wrote: Let me ask again in a different way ;-) Specifically about LCD style antialiasing. What about a context attribute antialiasRenderingQualityHint for now with 2 settings default and displayDependent context.antialiasRenderingQualityHint = displayDependent How would this interact with canvas opacity? E.g. if the author uses displayDependent and then draws text over transparent pixels in the canvas, what is the UA supposed to do? Whatever the UA wants. It's a hint. From my POV, since the spec doesn't say anything about anti-aliasing then it really doesn't matter. My preference, if I was programming a UA, would be if the user sets displayDependent and the UA is running on a lo-dpi machine I'd unconditionally render LCD-AA with the assumption that the canvas is composited on white. If they want some other color they'd fill the canvas with as solid color first. Personally I don't think that needs to be specced, but it would be my suggestion. As I mentioned, even without this hint the spec doesn't prevent a UA from unconditionally using LCD-AA. Very few developers are going to run into issues. Most developers that use canvas aren't going to set the hint. Most developers that use canvas dont' make it transparent nor do they CSS rotate/scale them. For those few developers that do happen to blend and/or rotate/scale AND set the hint they'll get probably get some fringing but there (a) there was no guarantee they wouldn't already have that problem since as pointed out, the spec doesn't specify AA nor what kind, and (b) if they care they'll either stop using the hint or they'll search for why is my canvas fringy and the answer will pop up on stackoverlow and they can choose one of the solutions. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Let me ask again in a different way ;-) Specifically about LCD style antialiasing. What about a context attribute antialiasRenderingQualityHint for now with 2 settings default and displayDependent context.antialiasRenderingQualityHint = displayDependent I'm thinking of it like this. The canvas spec does not say how antialiasing works or even that it exists so right now a UA is free to antialias in anyway it sees fit. It can do no antialiasing. It can do LCD antialiasing. It can do alpha antialiasing. It can use different algorithms. In fact, the software rasterizers between Firefox and Chrome already antialias different as do different GPUs. All we're looking for is some way to hint that we'd prefer LCD antialiasing if the UA thinks it's best for a given situation. We already can't count on a certain quality or algorithm context.antialiasRenderingQualityHint = displayDependent The advantage to this hint is that (a) a UA is free it ignore it and rendering will not be any worse/better than it is now and (b) as the world moves to HD-DPI everywhere UAs will pick alpha-AA and things just magically work. As for rotating, scaling, blending a cavnas it's up to the app to opt into this hint and it's up to the UA when to honor it. I'm not seeing the downside here. You're not breaking anything because the app already has no idea what kind of AA a UA is using. The hint is forward compatible as well. The only place I see an issue is UA zooming. But if the app really cares and if we really care we can provide an API to figure out the zoom level. Then an app that cares can change the size of their canvas's backingstore so its 1:1 device pixels for a given zoom level and re-render. Lots of apps would like to do that with or without the proposed hint as it would let them zoom in a way that matches the text and svg on the page. Everybody wins! :-) 1) not ant alias 2) antialias in any way it sees fit could happily implement LCD style AA and still be spec complien
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 10:28 PM, Gregg Tavares g...@google.com wrote: On Wed, Mar 13, 2013 at 1:18 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Mar 14, 2013 at 8:04 AM, Gregg Tavares g...@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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 2:48 PM, Gregg Tavares g...@google.com wrote:
Sorry for only mentioning this so late but is there any chance to steer
this to be more inline with WebGL?
WebGL already has the option to have an opaque canvas using context
creation parameters. In WebGL it's
gl = canvas.getContext(webgl, {alpha: false});
If we go forward with an opaque attribute now you have 2 conflicting
settings.
canvas.opaque = true;
gl = canvas.getContext(webgl, {alpha: true});
Who wins that conflict? Yea, I know we could come up with rules. ( the 2
settings, etc...)
But, there are other context creation attributes we'd like to see on a 2d
canvas. One that comes to mind is 'preserveDrawingBuffer'.
preserveDrawingBuffer: false in WebGL means that the canvas is double
buffered. This is a performance win since most browsers using GPU
compositing need to copy the contents of the canvas when compositing.
Setting preseverDrawingBuffer: false (which is the default in WebGL) means
the browser can double buffer and avoid the copy. We'd like to see that
same attribute for 2D canvas/contexts to get the same perf benefit for
canvas games, etc.
So, given we want more creation attributes and given WebGL already has a
way to declare opaqueness why not follow the existing method and add
context creation parameters to 2d canvas to solve this issue rather than
make a new and conflicting 'opaque' attribute?
I have no major objections to this approach, so long as it doesn't make
this change contingent on a WebGL spec change. In particular, it's
tempting to unify the IDL between Canvas WebGL (although it may not be
necessary -- I'm far from an IDL expert.) Here, let me show you my
ignorance: can we create a
interface Canvas2DContextAttributes {
attribute boolean alpha;
}
which has no relation to WebGLContextAttributes?
Then we get at least the duck typing such that
ctx = canvas.getContext('2d', {alpha: false });
and
ctx = canvas.getContext('webgl', {alpha: false });
both work, although one is coerced into a WebGLContextAttributes and the
other to a Canvas2DContextAttributes.
Does that make sense?
Stephen
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 3/14/13 10:34 AM, Stephen White wrote:
can we create a
interface Canvas2DContextAttributes {
attribute boolean alpha;
}
which has no relation to WebGLContextAttributes?
Yes.
Then we get at least the duck typing such that
ctx = canvas.getContext('2d', {alpha: false });
and
ctx = canvas.getContext('webgl', {alpha: false });
both work, although one is coerced into a WebGLContextAttributes and the
other to a Canvas2DContextAttributes.
And this would work, yes.
-Boris
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 4:51 PM, Rik Cabanier caban...@gmail.com wrote: Also, should opaque go on CanvasRenderingContext2D or the canvas object? If it's applied to the canvas object, it seems that it should apply to WebGL too. Does Firefox apply this to WebGL contexts? We don't, but ideally we would. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Sorry for only mentioning this so late but is there any chance to steer
this to be more inline with WebGL?
WebGL already has the option to have an opaque canvas using context
creation parameters. In WebGL it's
gl = canvas.getContext(webgl, {alpha: false});
If we go forward with an opaque attribute now you have 2 conflicting
settings.
canvas.opaque = true;
gl = canvas.getContext(webgl, {alpha: true});
Who wins that conflict? Yea, I know we could come up with rules. ( the 2
settings, etc...)
But, there are other context creation attributes we'd like to see on a 2d
canvas. One that comes to mind is 'preserveDrawingBuffer'.
preserveDrawingBuffer: false in WebGL means that the canvas is double
buffered. This is a performance win since most browsers using GPU
compositing need to copy the contents of the canvas when compositing.
Setting preseverDrawingBuffer: false (which is the default in WebGL) means
the browser can double buffer and avoid the copy. We'd like to see that
same attribute for 2D canvas/contexts to get the same perf benefit for
canvas games, etc.
So, given we want more creation attributes and given WebGL already has a
way to declare opaqueness why not follow the existing method and add
context creation parameters to 2d canvas to solve this issue rather than
make a new and conflicting 'opaque' attribute?
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Another question: And I see this brought up above 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 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. As a developer I'd like to be able to chose an opaque canvas for perf since compositing an opaque canvas on the page (with GPU blending off) is significantly faster than with it on. Choosing opaque for perf I shouldn't then suddenly get anti-aliasing that doesn't fit my use case. A typical example is to scale a canvas that is smaller than the size it will be displayed to get more perf or to get a pixelated retro look. It would be less than desirable if I also mark the canvas as opaque to get perf and suddenly my scaled canvas has color fringing all over the place.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Mar 14, 2013 at 8:04 AM, Gregg Tavares g...@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 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. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 1:18 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Mar 14, 2013 at 8:04 AM, Gregg Tavares g...@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 ;-) 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 11:48 AM, Gregg Tavares g...@google.com wrote:
Sorry for only mentioning this so late but is there any chance to steer
this to be more inline with WebGL?
WebGL already has the option to have an opaque canvas using context
creation parameters. In WebGL it's
gl = canvas.getContext(webgl, {alpha: false});
If we go forward with an opaque attribute now you have 2 conflicting
settings.
canvas.opaque = true;
gl = canvas.getContext(webgl, {alpha: true});
Who wins that conflict? Yea, I know we could come up with rules. ( the 2
settings, etc...)
But, there are other context creation attributes we'd like to see on a 2d
canvas. One that comes to mind is 'preserveDrawingBuffer'.
preserveDrawingBuffer: false in WebGL means that the canvas is double
buffered. This is a performance win since most browsers using GPU
compositing need to copy the contents of the canvas when compositing.
Setting preseverDrawingBuffer: false (which is the default in WebGL) means
the browser can double buffer and avoid the copy. We'd like to see that
same attribute for 2D canvas/contexts to get the same perf benefit for
canvas games, etc.
So, given we want more creation attributes and given WebGL already has a
way to declare opaqueness why not follow the existing method and add
context creation parameters to 2d canvas to solve this issue rather than
make a new and conflicting 'opaque' attribute?
It seems that we should follow the path that WebGL followed so it's not
confusing for authors.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 2013/03/13 2:03, Stephen White wrote: Description: The opaque attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the opaque attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead.m Could we align this with the existing WebGL canvas attribute instead of having similar but opposite attributes on each. I.e. instead of opaque have alpha. When false the canvas is opaque (and it is not necessary to store alpha values in the backing store). When true, the canvas is potentially translucent. The default for alpha is true so that matches the proposed default for opaque. It will cause much less confusion if the same attribute serves the same purpose on both types of canvas. FYI, the description of the attribute in the WebGL spec is: If the value is true, the drawing buffer has an alpha channel for the purposes of performing OpenGL destination alpha operations and compositing with the page. If the value is false, no alpha buffer is available. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Mon, Mar 11, 2013 at 4:32 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 12, 2013 at 8:23 AM, Stephen White senorbla...@chromium.orgwrote: On Mon, Mar 11, 2013 at 2:56 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 12, 2013 at 7:53 AM, Stephen White senorbla...@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()). We definitely shouldn't spec that! And I'm pretty sure that behavior would vary across Firefox platforms. But we need to have consistent behavior here. 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. You can always implement it slowly using readback. I think we should just spec this, and maybe note that authors shouldn't use non-over operators on opaque canvases. Over time we'll probably find a way to make it fast everywhere. I'm a little leery of spec'ing something that has negative performance implications. As an example, the darker compositing mode was removed from the spec due to hardware-accelerated performance concerns, IIRC. OTOH, unlike that change, this spec should not have performance implications for OpenGL or Direct3D acceleration, only CoreGraphics via IOSurface and skia (so far). How would you feel about simply mapping the dest-alpha-modifying compositing modes to source-over, as in proposal 2) above? 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Here's a draft of proposal (1) above: Motivation: Compositing a canvas element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas. Description: The opaque attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the opaque attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead. When a canvas has the opaque attribute, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). Setting, changing, removing or setting the attribute redundantly to its existing value causes the canvas to be cleared to the appropriate value. When a canvas has the opaque attribute, clearRect() clears to opaque black instead of transparent black. The behaviour of putImageData() and putImageDataHD() when a canvas has the opaque attribute is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store. When a canvas has the opaque attribute, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the alpha component is left unchanged at 1.0. Stephen On Tue, Mar 12, 2013 at 12:53 PM, Stephen White senorbla...@chromium.orgwrote: On Mon, Mar 11, 2013 at 4:32 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 12, 2013 at 8:23 AM, Stephen White senorbla...@chromium.orgwrote: On Mon, Mar 11, 2013 at 2:56 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Mar 12, 2013 at 7:53 AM, Stephen White senorbla...@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()). We definitely shouldn't spec that! And I'm pretty sure that behavior would vary across Firefox platforms. But we need to have consistent behavior here. 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. You can always implement it slowly using readback. I think we should just spec this, and maybe note that authors shouldn't use non-over operators on opaque canvases. Over time we'll probably find a way to make it fast everywhere. I'm a little leery of spec'ing something that has negative performance implications. As an example, the darker compositing mode was removed from the spec due to hardware-accelerated performance concerns, IIRC. OTOH, unlike that change, this spec should not have performance implications for OpenGL or Direct3D acceleration, only CoreGraphics via IOSurface and skia (so far). How would you feel about simply mapping the dest-alpha-modifying compositing modes to source-over, as in proposal 2) above? 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 5:53 AM, Stephen White senorbla...@chromium.orgwrote: I'm a little leery of spec'ing something that has negative performance implications. So am I, but surely making non-over operators slower is better than making them not work at all --- especially if the former situation is temporary. The latter decision would have to be permanent. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, 12 Mar 2013, Stephen White wrote: As an example, the darker compositing mode was removed from the spec due to hardware-accelerated performance concerns, IIRC. 'darker' was removed because it wasn't defined anywhere so couldn't be implemented interoperably. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Mar 12, 2013 at 10:03 AM, Stephen White senorbla...@chromium.orgwrote: Here's a draft of proposal (1) above: Motivation: Compositing a canvas element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas. Description: The opaque attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the opaque attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead. When a canvas has the opaque attribute, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). Setting, changing, removing or setting the attribute redundantly to its existing value causes the canvas to be cleared to the appropriate value. When a canvas has the opaque attribute, clearRect() clears to opaque black instead of transparent black. The behaviour of putImageData() and putImageDataHD() when a canvas has the opaque attribute is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store. When a canvas has the opaque attribute, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the alpha component is left unchanged at 1.0. What does 'normal' mean? Is it 'composite with the usual formula' or 'composite with source-over'? I still think a matteColor can accomplish the same and have the added benefit of flexibility and easy of specification... On Tue, Mar 12, 2013 at 12:53 PM, Stephen White senorbla...@chromium.orgwrote: On Mon, Mar 11, 2013 at 4:32 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 12, 2013 at 8:23 AM, Stephen White senorbla...@chromium.org wrote: On Mon, Mar 11, 2013 at 2:56 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Mar 12, 2013 at 7:53 AM, Stephen White senorbla...@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()). We definitely shouldn't spec that! And I'm pretty sure that behavior would vary across Firefox platforms. But we need to have consistent behavior here. 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. You can always implement it slowly using readback. I think we should just spec this, and maybe note that authors shouldn't use non-over operators on opaque canvases. Over time we'll probably find a way to make it fast everywhere. I'm a little leery of spec'ing something that has negative performance implications. As an example, the darker compositing mode was removed from the spec due to hardware-accelerated performance concerns, IIRC. OTOH, unlike that change, this spec should not have performance implications for OpenGL or Direct3D acceleration, only CoreGraphics via IOSurface and skia (so far). How would you feel about simply mapping the dest-alpha-modifying compositing modes to source-over, as in proposal 2) above? Stephen Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz,
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Mar 12, 2013 at 3:08 PM, Stephen White senorbla...@chromium.orgwrote: On Tue, Mar 12, 2013 at 5:36 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:03 AM, Stephen White senorbla...@chromium.org wrote: Here's a draft of proposal (1) above: Motivation: Compositing a canvas element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well to cull fully-obscured elements behind the canvas. Description: The opaque attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be 1.0 at all times. All canvas operations are modified to preserve this invariant. If the opaque attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead. When a canvas has the opaque attribute, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). Setting, changing, removing or setting the attribute redundantly to its existing value causes the canvas to be cleared to the appropriate value. When a canvas has the opaque attribute, clearRect() clears to opaque black instead of transparent black. The behaviour of putImageData() and putImageDataHD() when a canvas has the opaque attribute is to premultiply the RGB components by the alpha component as usual, but write 1.0 into destination alpha. In other words, if (r, g, b, a) are the component values in a given pixel passed to putImageData[HD](), then r' = ar, g' = ag, b' = ab are the colour components of the resulting canvas pixel, and (r', g', b', 1.0) is written to the canvas backing store. When a canvas has the opaque attribute, all globalCompositeOperation modes behave as normal and the resulting RGB components are written to the canvas backing store, but the alpha component is left unchanged at 1.0. What does 'normal' mean? Is it 'composite with the usual formula' or 'composite with source-over'? Normal means composite with the usual formula. Composite with source-over would be proposal 2) above (but only for those modes which could leave destination alpha at something other than 1.0). Here is what I think the modified compositing math would be for proposal 1) above: mode result opaque result would require opaque mode clear [0, 0] [1, 0] 0 == 1 clear-opaque source-over [Sa + (1 - Sa) * Da, Sc + (1 - Sa) * Dc] [1, Sc + (1 - Sa) * Dc] 1 == 1 source-over source-in [Da * Sa, Da * Sc] [1, Sc] Sa == 1 copy-opaque source-out [(1 - Da) * Sa, (1 - Da) * Sc] [1, 0] 0 == 1 clear-opaque source-atop [Da, Da * Sc + (1 - Sa) * Dc] [1, Sc + (1 - Sa) * Dc] 1 == 1source-atop destination-over [(1 - Da) * Sa + Da, (1 - Da) * Sc + Dc] [1, Dc + (1 - Da) * Sc] 1 == 1 destination-over destination-in [Sa * Da, Sa * Dc] [1, Sa * Dc] Sa == 1destination-in-opaque destination-out [(1 - Sa) * Da, (1 - Sa) * Dc] [1, (1 - Sa) * Dc] Sa == 0xor-opaque destination-atop [Sa, (1 - Da) * Sc + Sa * Dc] [1, Sa * Dc] Sa == 1destination-in-opaque lighter [Sa + Da, Sc + Dc] [1, Sc + Dc] Sa = 0 lighter darker sc * da dc * sa ? srcover : dstover sc dc * sa ? srcover : dstover 1 == 1 darker copy [Sa, Sc] [1, Sc] Sa == 1 copy-opaque xor [(1 - Da) * Sa + (1 - Sa) * Da, (1 - Da) * Sc + (1 - Sa) * Dc] [1, (1 - Sa) * Dc] Sa == 1 xor-opaque (Note: the opaque mode contains some names I made up for the 4 new required modes, but that's just for reference -- these names would not appear in the spec or the API). That looks correct. Did you add darker because you believe it should be added to the list of supported compositing modes? Also, should opaque go on CanvasRenderingContext2D or the canvas object? If it's applied to the canvas object, it seems that it should apply to WebGL too. Does Firefox apply this to WebGL contexts?
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
Here's a first draft of a proposal to standardize moz-opaque. (Note that Firefox/Linux and Firefox/Win differ in their implementation of moz-opaque. This proposal is most similar to the Firefox/Linux implementation, but with the canvas cleared to opaque black as in the Firefox/Win version). Motivation: Compositing a canvas element into the page can be expensive, due to blending operations, and lack of opportunity for culling. Since arbitrary graphics operations can affect the opacity of the canvas, it is difficult to determine programmatically whether the canvas is opaque. Allowing the developer to explicitly mark a canvas as opaque allows the user agent to optimize blending at page composite time, as well as culling obscured elements behind the canvas. Description: The opaque attribute is a boolean attribute of the canvas element, whose presence indicates that the alpha values in the canvas backing store must be ignored when compositing the canvas into the page. If the attribute is not present, or if parsing its value returns an error, then the default value (false) must be used instead. When a canvas has the opaque attribute, the backing store must be initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent black (rgba(0, 0, 0, 0.0)). Changing or removing the attribute after initialization causes the canvas to be cleared to the appropriate value. 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. Stephen On Fri, Mar 8, 2013 at 6:57 PM, Stephen White senorbla...@chromium.orgwrote: On Sat, Feb 23, 2013 at 6:48 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Feb 23, 2013 at 4:59 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.comwrote: On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. 3) It still can't handle all cases, such as canvas - WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. I agree those are problems. All of the available options have problems. Given that that's the case, I am going to move forward with the opaque attribute, since I feel it is the lesser of all the evils presented thus far. Paying the cost of two buffers and double-rendering just isn't palatable, IMHO. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? Perhaps we could use text-rendering:optimizeLegibility on the canvas element. We also might be over-thinking the danger that LCD AA poses. Firefox/Linux and Firefox/Mac are both currently shipping with LCD AA turned on unconditionally in canvas, and it's trivial to make them expose color fringing. WebKit nightlies (Safari build) seem do the same, although Safari 6.0 doesn't. Stephen I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. Maybe. Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. I agree. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Mar 12, 2013 at 7:53 AM, Stephen White senorbla...@chromium.orgwrote: 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. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Mon, Mar 11, 2013 at 2:56 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 12, 2013 at 7:53 AM, Stephen White senorbla...@chromium.orgwrote: 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Mar 12, 2013 at 8:23 AM, Stephen White senorbla...@chromium.orgwrote: On Mon, Mar 11, 2013 at 2:56 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 12, 2013 at 7:53 AM, Stephen White senorbla...@chromium.orgwrote: 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()). We definitely shouldn't spec that! And I'm pretty sure that behavior would vary across Firefox platforms. But we need to have consistent behavior here. 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. You can always implement it slowly using readback. I think we should just spec this, and maybe note that authors shouldn't use non-over operators on opaque canvases. Over time we'll probably find a way to make it fast everywhere. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 23, 2013 at 6:48 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Feb 23, 2013 at 4:59 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. 3) It still can't handle all cases, such as canvas - WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. I agree those are problems. All of the available options have problems. Given that that's the case, I am going to move forward with the opaque attribute, since I feel it is the lesser of all the evils presented thus far. Paying the cost of two buffers and double-rendering just isn't palatable, IMHO. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? Perhaps we could use text-rendering:optimizeLegibility on the canvas element. We also might be over-thinking the danger that LCD AA poses. Firefox/Linux and Firefox/Mac are both currently shipping with LCD AA turned on unconditionally in canvas, and it's trivial to make them expose color fringing. WebKit nightlies (Safari build) seem do the same, although Safari 6.0 doesn't. Stephen I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. Maybe. Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. I agree. 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]
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 senorbla...@chromium.orgwrote: On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier caban...@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 rob...@ocallahan.orgwrote: On Tue, Feb 19, 2013 at 5:19 PM, Stephen White senorbla...@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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
* Rik Cabanier wrote: 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. The article seems to be about Windows 8 and neither it nor the comments seem to discuss Internet Explorer 10 on Windows 7. Are you sure this is a property of Internet Explorer 10 regardless of the Windows version, and given that the article is a year old, that this is still current? -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
I experimented a bit and t is still active on Windows 7. On Tue, Feb 26, 2013 at 10:11 AM, Bjoern Hoehrmann derhoe...@gmx.netwrote: * Rik Cabanier wrote: 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. The article seems to be about Windows 8 and neither it nor the comments seem to discuss Internet Explorer 10 on Windows 7. Are you sure this is a property of Internet Explorer 10 regardless of the Windows version, and given that the article is a year old, that this is still current? -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 23, 2013 at 4:59 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. 3) It still can't handle all cases, such as canvas - WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. I agree those are problems. All of the available options have problems. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? Perhaps we could use text-rendering:optimizeLegibility on the canvas element. I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. Maybe. Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. I agree. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan rob...@ocallahan.orgwrote: I think Rik is convincing me that we shouldn't expose mozOpaque or any other explicit subpixel AA control to the Web. It will be very easy for Web authors to test it in one place and discover that it works without realizing that they're causing problems for some users. I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. 3) It still can't handle all cases, such as canvas - WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. Great! I think matteColor (or matteStyle to be more consistent) can easily be implemented. We can optimize rendering later. So, if a mattecolor is set the UA can assume that: Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. Stephen - all compositing operation within the canvas can ignore background alpha - the canvas can be copied directly to the screen (unless another effect is applied to the canvas element or its ancestor) If mattecolor is set, the UA should matte with that color. If a compositing operation (that introduces alpha) is used, the matte operation needs to be repeated. Rik
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Feb 22, 2013 at 7:59 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think Rik is convincing me that we shouldn't expose mozOpaque or any other explicit subpixel AA control to the Web. It will be very easy for Web authors to test it in one place and discover that it works without realizing that they're causing problems for some users. I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. 3) It still can't handle all cases, such as canvas - WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. Since this is a feature for advanced users, we should let them handle all the cases. (I would even allow subpixel AA on a transparent canvas) Handling all the edge cases in the browser will be extremely difficult (if it's even possible) and will just frustrate those advanced users since it will get in their way. Great! I think matteColor (or matteStyle to be more consistent) can easily be implemented. We can optimize rendering later. So, if a mattecolor is set the UA can assume that: Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. Doesn't that seem slightly hacky? So, if the canvas detects that you did a fillrect with a constant color, it should assume that it's opaque? This seems confusing from an author's perspective. In addition, compositing modes that introduce alpha will turn the bit off again and there would be no way to turn it back on. - all compositing operation within the canvas can ignore background alpha - the canvas can be copied directly to the screen (unless another effect is applied to the canvas element or its ancestor) If mattecolor is set, the UA should matte with that color. If a compositing operation (that introduces alpha) is used, the matte operation needs to be repeated. Rik
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 23, 2013 at 2:59 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think Rik is convincing me that we shouldn't expose mozOpaque or any other explicit subpixel AA control to the Web. It will be very easy for Web authors to test it in one place and discover that it works without realizing that they're causing problems for some users. I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) What is the performance hit? 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. Why are there 2 buffers? You just draw on top of the existing content. It is up to the author to ensure correct output. 3) It still can't handle all cases, such as canvas - WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. That is OK. A UA is not required to implement this. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. Great! I think matteColor (or matteStyle to be more consistent) can easily be implemented. We can optimize rendering later. So, if a mattecolor is set the UA can assume that: Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. Stephen - all compositing operation within the canvas can ignore background alpha - the canvas can be copied directly to the screen (unless another effect is applied to the canvas element or its ancestor) If mattecolor is set, the UA should matte with that color. If a compositing operation (that introduces alpha) is used, the matte operation needs to be repeated. I experimented with adding MatteStyle for Core Graphics in mozilla and webkit and got the basics of it working. So, it's definitely possible to add to the browsers.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier caban...@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 rob...@ocallahan.orgwrote: On Tue, Feb 19, 2013 at 5:19 PM, Stephen White senorbla...@chromium.orgwrote: 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
I think Rik is convincing me that we shouldn't expose mozOpaque or any other explicit subpixel AA control to the Web. It will be very easy for Web authors to test it in one place and discover that it works without realizing that they're causing problems for some users. I think a fully automatic solution that tries to use subpixel AA but is always able to render grayscale AA if needed is the way to go. Possibly with an author hint to suggest opting into a more expensive rendering path. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
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? On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Feb 19, 2013 at 5:19 PM, Stephen White senorbla...@chromium.orgwrote: 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Feb 16, 2013 at 11:09 AM, Stephen White
senorbla...@chromium.orgwrote:
On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White senorbla...@chromium.org
wrote:
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).
I don't think that's a problem. All destination alpha values will be 1
even after the subpixel AA test is painted, and you'll treat it as normal.
I was thinking something like this:
- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text
Now some of the subpixel AA text is still there, but the destination
alpha is non-1, so things will go bad when you composite into the page.
(At least I think it will.. Porter-Duff makes my head spin sometimes.)
I don't see the problem. After the first step, you have an RGBA buffer
that represents exactly the result of the rendering. The second step treats
it exactly like any other RGBA buffer. Am I being dense?
No, it's probably me. I was thinking that since there was a way to
introduce non-1 alpha into the backing store after-the-fact, it would break
the previously-performed subpixel coverage blending. But perhaps not.
The suggestion on the list earlier was to keep two versions of the canvas
buffer: one with grayscale AA, another with subpixel AA, and composite with
the subpixel AA buffer when we can do that safely, otherwise use the
grayscale AA version. In many implementations there would be a performance
hit for this, so it would make sense to have authors opt-in to that
performance hit.
It would also be a needless performance hit if the developer knew that
they always wanted subpixel AA, and that their app would never fringe.
I don't think the developer can ever know that. They'd have to assume the
browser/platform does not have a quick-zoom feature, which is an assumption
developers shouldn't be making. Although I guess we could just declare that
that case isn't important enough to matter.
Well, pretty much all devices that have pinch-zoom today are high-DPI, and
don't implement subpixel AA. :) But no, I don't think that's not a good
assumption to bake into the web platform.
So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):
moz-opaque
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
Additional con: requires changes to canvas compositing spec and possibly
implementations.
Yes, since it's new behaviour it'll require spec changes. I guess we can
consider that as part of con of being opt-in.
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL, etc
context attribute (something like: context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
Additional con: requires specification and implementation of what happens
when subpixel AA is drawn over transparent background.
deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that
never clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
Not really true, you can just give up on the complex cases and draw
grayscale whenever you feel like it.
And leave the behaviour unspecified, I'm guessing? Doesn't that least to
inconsistent behaviour between browsers? Even within one implementation,
if you had content whose command stream varied over the maximum buffer
length threshold, it'd toggle between subpixel and grayscale AA. Not sure
if this is a case worth worrying about, but it does feel like it's exposing
more of the implementation that one would like.
Stephen
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone without)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Feb 19, 2013 at 12:01 PM, Stephen White senorbla...@chromium.orgwrote: On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan rob...@ocallahan.orgwrote: Not really true, you can just give up on the complex cases and draw grayscale whenever you feel like it. And leave the behaviour unspecified, I'm guessing? Doesn't that least to inconsistent behaviour between browsers? Even within one implementation, if you had content whose command stream varied over the maximum buffer length threshold, it'd toggle between subpixel and grayscale AA. Not sure if this is a case worth worrying about, but it does feel like it's exposing more of the implementation that one would like. You could avoid toggling by disabling subpixel AA permanently if you're forced over the buffer threshold. I don't think we should try to specify exactly when subpixel AA happens. There's huge variation across platforms and UAs already and it very rarely matters for interop; when subpixel AA fails the site still works. I think we should treat this as a quality-of-implementation issue, possibly assisted by author hints. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Mon, Feb 18, 2013 at 4:01 PM, Stephen White senorbla...@chromium.orgwrote:
On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Feb 16, 2013 at 11:09 AM, Stephen White senorbla...@chromium.org
wrote:
On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White
senorbla...@chromium.org wrote:
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).
I don't think that's a problem. All destination alpha values will be 1
even after the subpixel AA test is painted, and you'll treat it as normal.
I was thinking something like this:
- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text
Now some of the subpixel AA text is still there, but the destination
alpha is non-1, so things will go bad when you composite into the page.
(At least I think it will.. Porter-Duff makes my head spin sometimes.)
I don't see the problem. After the first step, you have an RGBA buffer
that represents exactly the result of the rendering. The second step treats
it exactly like any other RGBA buffer. Am I being dense?
No, it's probably me. I was thinking that since there was a way to
introduce non-1 alpha into the backing store after-the-fact, it would break
the previously-performed subpixel coverage blending. But perhaps not.
If MozOpaque is set or matteColor (or some other property that we can agree
upon), you will be guaranteed that there will never be alpha in the backing
store when you draw the text. We would also need to define under what
compositing modes subpixel AA happens.
The suggestion on the list earlier was to keep two versions of the
canvas buffer: one with grayscale AA, another with subpixel AA, and
composite with the subpixel AA buffer when we can do that safely, otherwise
use the grayscale AA version. In many implementations there would be a
performance hit for this, so it would make sense to have authors opt-in to
that performance hit.
It would also be a needless performance hit if the developer knew that
they always wanted subpixel AA, and that their app would never fringe.
I don't think the developer can ever know that. They'd have to assume the
browser/platform does not have a quick-zoom feature, which is an assumption
developers shouldn't be making. Although I guess we could just declare that
that case isn't important enough to matter.
Well, pretty much all devices that have pinch-zoom today are high-DPI, and
don't implement subpixel AA. :) But no, I don't think that's not a good
assumption to bake into the web platform.
So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):
moz-opaque
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
Additional con: requires changes to canvas compositing spec and possibly
implementations.
Yes, since it's new behaviour it'll require spec changes. I guess we can
consider that as part of con of being opt-in.
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL,
etc
context attribute (something like: context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
Additional con: requires specification and implementation of what happens
when subpixel AA is drawn over transparent background.
deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that
never clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
Not really true, you can just give up on the complex cases and draw
grayscale whenever you feel like it.
And leave the behaviour unspecified, I'm guessing? Doesn't that least to
inconsistent behaviour between browsers? Even within one implementation,
if you had content whose command stream varied over the maximum buffer
length threshold, it'd toggle between subpixel and grayscale AA. Not sure
if this is a case worth worrying about, but it does feel like it's exposing
more of the implementation that one would
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 4:12 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Feb 16, 2013 at 11:09 AM, Stephen White senorbla...@chromium.orgwrote: deferred canvas rendering (collect commands into a buffer, flush buffer only when compositing canvas to page, and decide on subpixel AA at that point) pro: catches all cases of color fringing con: in some cases, requires an infinite buffer (e.g., a canvas that never clears, and only accumulates drawing frame-to-frame means you must accumulate commands indefinitely) con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc) con: may introduce performance hit due to re-rendering with and without subpixel AA (in cases where you would rather have just gone without) two buffers (one grayscale, one LCD AA) pro: handles all cases of color fringing pro: moderately easy to implement con: RAM (or VRAM) usage is doubled con: possibly-unnecessary performance hit con: must be opt-in Both of these schemes can actually be optimized some more: As long as no text is drawn to a canvas, you can freely rasterize (in the first case) or use just one buffer (in the second case). In fact, this is true as long as no text is drawn to a canvas over non-opaque pixels. So a lot of canvas usage could be handled with little or no performance hit. 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. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Feb 19, 2013 at 5:19 PM, Stephen White senorbla...@chromium.orgwrote: 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 11:09 AM, Stephen White senorbla...@chromium.orgwrote:
On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White
senorbla...@chromium.orgwrote:
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).
I don't think that's a problem. All destination alpha values will be 1
even after the subpixel AA test is painted, and you'll treat it as normal.
I was thinking something like this:
- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text
Now some of the subpixel AA text is still there, but the destination
alpha is non-1, so things will go bad when you composite into the page.
(At least I think it will.. Porter-Duff makes my head spin sometimes.)
I don't see the problem. After the first step, you have an RGBA buffer that
represents exactly the result of the rendering. The second step treats it
exactly like any other RGBA buffer. Am I being dense?
The suggestion on the list earlier was to keep two versions of the canvas
buffer: one with grayscale AA, another with subpixel AA, and composite with
the subpixel AA buffer when we can do that safely, otherwise use the
grayscale AA version. In many implementations there would be a performance
hit for this, so it would make sense to have authors opt-in to that
performance hit.
It would also be a needless performance hit if the developer knew that
they always wanted subpixel AA, and that their app would never fringe.
I don't think the developer can ever know that. They'd have to assume the
browser/platform does not have a quick-zoom feature, which is an assumption
developers shouldn't be making. Although I guess we could just declare that
that case isn't important enough to matter.
So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):
moz-opaque
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
Additional con: requires changes to canvas compositing spec and possibly
implementations.
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL, etc
context attribute (something like: context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
Additional con: requires specification and implementation of what happens
when subpixel AA is drawn over transparent background.
deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that
never clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
Not really true, you can just give up on the complex cases and draw
grayscale whenever you feel like it.
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone without)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or VRAM) usage is doubled
con: possibly-unnecessary performance hit
con: must be opt-in
Sounds right with the above modifications.
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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 11:09 AM, Stephen White senorbla...@chromium.orgwrote: deferred canvas rendering (collect commands into a buffer, flush buffer only when compositing canvas to page, and decide on subpixel AA at that point) pro: catches all cases of color fringing con: in some cases, requires an infinite buffer (e.g., a canvas that never clears, and only accumulates drawing frame-to-frame means you must accumulate commands indefinitely) con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc) con: may introduce performance hit due to re-rendering with and without subpixel AA (in cases where you would rather have just gone without) two buffers (one grayscale, one LCD AA) pro: handles all cases of color fringing pro: moderately easy to implement con: RAM (or VRAM) usage is doubled con: possibly-unnecessary performance hit con: must be opt-in Both of these schemes can actually be optimized some more: As long as no text is drawn to a canvas, you can freely rasterize (in the first case) or use just one buffer (in the second case). In fact, this is true as long as no text is drawn to a canvas over non-opaque pixels. So a lot of canvas usage could be handled with little or no performance hit. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@chromium.orgwrote: 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. Stephen 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? 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 2:35 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@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? http://en.wikipedia.org/wiki/Subpixel_rendering 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? 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
As an other alternative, we could also introduce a 'matteColor' attribute. It's default would be 'transparent'. If it's set to a css color, the canvas will be matted to that color. In addition if you use putImageData or a compositing operator that changes alpha, you always matte with that color afterwards (if needed). This is actually pretty close to the 'opaque' keyword except - it's on the canvas context - you can specify a color - it doesn't force reallocation of the canvas On Fri, Feb 15, 2013 at 2:44 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@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'. Yes, that's pretty much my proposal. Except putImageData could detect it but that might be too hard for authors to figure out. 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? I think that would be very helpful. So, if you clear (or matte) the canvas, the flag becomes true but if you do an operator that removes alpha, it will become false. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White senorbla...@chromium.orgwrote: 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. This came up on the list earlier. 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). I don't think that's a problem. All destination alpha values will be 1 even after the subpixel AA test is painted, and you'll treat it as normal. 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. It's difficult to know that on a mobile browser or any other browser where you have some kind of fast zoom UI. The suggestion on the list earlier was to keep two versions of the canvas buffer: one with grayscale AA, another with subpixel AA, and composite with the subpixel AA buffer when we can do that safely, otherwise use the grayscale AA version. In many implementations there would be a performance hit for this, so it would make sense to have authors opt-in to that performance hit. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White
senorbla...@chromium.orgwrote:
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.
This came up on the list earlier.
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).
I don't think that's a problem. All destination alpha values will be 1
even after the subpixel AA test is painted, and you'll treat it as normal.
I was thinking something like this:
- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text
Now some of the subpixel AA text is still there, but the destination alpha
is non-1, so things will go bad when you composite into the page. (At
least I think it will.. Porter-Duff makes my head spin sometimes.)
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.
It's difficult to know that on a mobile browser or any other browser where
you have some kind of fast zoom UI.
The suggestion on the list earlier was to keep two versions of the canvas
buffer: one with grayscale AA, another with subpixel AA, and composite with
the subpixel AA buffer when we can do that safely, otherwise use the
grayscale AA version. In many implementations there would be a performance
hit for this, so it would make sense to have authors opt-in to that
performance hit.
It would also be a needless performance hit if the developer knew that they
always wanted subpixel AA, and that their app would never fringe.
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]
So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):
moz-opaque
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL, etc
context attribute (something like: context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that never
clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone without)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or VRAM) usage is doubled
con: possibly-unnecessary performance hit
con: must be opt-in
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier caban...@gmail.com wrote: Looking at the WebKit implementation, I'm unsure how 'opaque' can implemented for accelerated canvas. It might work with non-accelerated canvas but would have to run some experiments. I also look at mozilla's Core Graphics implementation and unless I'm missing something, it doesn't have special code to handle 'opaque'. When do you use this parameter? CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That selects a surface format that is passed down to the graphics layer when creating the canvas surface. It's true that we don't currently do anything with that when drawing with CoreGraphics. That would need to be cleaned up before we started promoting this feature. Now that you mention it, having to modify the definition of compositing is a bit of a bummer for the 'opaque' attribute approach. I think we could do everything we want using your approach --- internally keeping a flag to indicate whether the alpha values of the canvas are all 1, setting it when the canvas is filled with a solid color and clearing it when non-over drawing (or clear()) are used. Let's try that! 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. We could consider separating the two concepts again. In an earlier thread, there was an attempt to automatically determine all the places where it's safe to enabled subpixel AA, but that seemed to result in a complex implementation, with all cases still not being covered (such as canvas-to-canvas drawImage()). The other alternative is programmatic control over subpixel AA, using a context attribute. That was the first thing that Justin proposed in the earlier thread, and would be my preference as well (a fully-loaded footgun: you can shoot yourself with it, but the behaviour and performance characteristics are very easy to understand and spec). But there didn't seem to be agreement around that either. Which is how I ended up at the moz-opaque flag. it restricts canvas to the subset of operations which result in a 1 alpha in the backing store, to allow optimizations and the use of subpixel AA. I think that is actually quite a useful subset (generally, the subset that doesn't need destination alpha). I believe the same thing can be achieved in WebGL by setting the alpha attribute to false in WebGLContextAttributes. Stephen But I think matte is unnecessarily obscure. How about adding a clear(DOMString) method that does a 'copy' of the color to the entire canvas buffer? The color could default to rgba(0,0,0,0). 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 2:59 AM, Stephen White senorbla...@chromium.orgwrote: On Wed, Feb 13, 2013 at 11:35 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier caban...@gmail.com wrote: Looking at the WebKit implementation, I'm unsure how 'opaque' can implemented for accelerated canvas. It might work with non-accelerated canvas but would have to run some experiments. I also look at mozilla's Core Graphics implementation and unless I'm missing something, it doesn't have special code to handle 'opaque'. When do you use this parameter? CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That selects a surface format that is passed down to the graphics layer when creating the canvas surface. It's true that we don't currently do anything with that when drawing with CoreGraphics. That would need to be cleaned up before we started promoting this feature. Now that you mention it, having to modify the definition of compositing is a bit of a bummer for the 'opaque' attribute approach. I think we could do everything we want using your approach --- internally keeping a flag to indicate whether the alpha values of the canvas are all 1, setting it when the canvas is filled with a solid color and clearing it when non-over drawing (or clear()) are used. Let's try that! 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. You only have to do that if you use compositing modes such as source-in though. In addition, you could detect at low cost that the CanvasImageSource is opaque so some compositing modes would not reset. 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. Yes, that is worrisome. It seems another flag is in ordre. We could consider separating the two concepts again. In an earlier thread, there was an attempt to automatically determine all the places where it's safe to enabled subpixel AA, but that seemed to result in a complex implementation, with all cases still not being covered (such as canvas-to-canvas drawImage()). The other alternative is programmatic control over subpixel AA, using a context attribute. That was the first thing that Justin proposed in the earlier thread, and would be my preference as well (a fully-loaded footgun: you can shoot yourself with it, but the behaviour and performance characteristics are very easy to understand and spec). But there didn't seem to be agreement around that either. Can you refresh me on the issue with that? Is the cost too high? Which is how I ended up at the moz-opaque flag. it restricts canvas to the subset of operations which result in a 1 alpha in the backing store, to allow optimizations and the use of subpixel AA. I think that is actually quite a useful subset (generally, the subset that doesn't need destination alpha). I believe the same thing can be achieved in WebGL by setting the alpha attribute to false in WebGLContextAttributes. My fear is that this is too disruptive as it changes how canvas compositing works. It might also not be implemented easily on all platforms (especially the ones that use the operating system to draw) But I think matte is unnecessarily obscure. How about adding a clear(DOMString) method that does a 'copy' of the color to the entire canvas buffer? The color could default to rgba(0,0,0,0). 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@chromium.orgwrote: 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'. 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? 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@chromium.orgwrote: 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'. Yes, that's pretty much my proposal. Except putImageData could detect it but that might be too hard for authors to figure out. 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? I think that would be very helpful. So, if you clear (or matte) the canvas, the flag becomes true but if you do an operator that removes alpha, it will become false. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Feb 12, 2013 at 6:14 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Feb 12, 2013 at 2:56 PM, Stephen White senorbla...@chromium.orgwrote: On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Jeremy Apthorp wrote: On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.org wrote: On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? Pixel-art style games. Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x). Do you have an example of a game where lines are drawn using a line API without antialiasing, then scaled up? Most pixel art games I've seen tend to use bitmaps for that kind of thing. On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? If LCD text were enable-able, authors would have to be mindful of a number of caveats in order to avoid rendering artifacts. Do we have any reason to believe the majority of authors would make the right decisions here? (The main reason we haven't provided control over things like antialiasing is that many authors tend to make terribly bad decisions.) (Before anyone gets offended, by the way: that you are reading this almost guarantees that you are above average in terms of authoring ability.) On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: We'd have to define what happens when you use subpixel antialiasing incorrectly, because we can be pretty sure authors will use it incorrectly and expect to get interoperable behavior. That's certainly true. Mozilla supports a mozOpaque attribute which makes the canvas buffer RGBX (initialized to solid black) and enables subpixel antialiasing for most text drawing. That might be enough to address your use-cases. I haven't specified this; if other vendors intend to implement this let me know and I can spec it. I'm not sure it's worth it though. [blowing the dust off this thread] Folks on the Chrome team are looking into implementing this attribute, and would be interested in seeing it spec'ed. What are you implementing? Initializing the canvas to black or subpixel antialiasing? We're interested in both aspects: the opportunity for culling and blending optimizations at composite time, as well as enabling subpixel AA. Stephen On Wed, 14 Nov 2012, Robert O'Callahan wrote: On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad ju...@chromium.org wrote: Are there precedents for exposing features with documented caveats? (excluding caveats that were discovered after the fact) Yes, and many of them have been extremely problematic, because Web authors will ignore the caveats. Right. I'd really like to avoid adding more if we can help it. On Wed, 14 Nov 2012, Justin Novosad wrote: There is a recent improvement in Chrome called deferred 2D canvas rendering (enabled by default as of Chrome 23). It is a mechanism that records 2d canvas commands during JS execution, and only executes them for real when the render buffer needs to be resolved (draw to screen, getImageData, toDataURL, etc.). If you want to check it out, the guts are in Skia: SkGPipe is a sort of FIFO for graphics commands, SkDeferredCanvas is a wrapper that manages the GPipe and automatically flushes it and applies some command culling optimizations. So to come back to the problem of with and without subpixel AA buffers: if rendering is deferred, the non-AA buffer would never get rasterized (and possibly never even allocated), unless it needs to be. Obviously there are practical limitations, for example we cannot store an unlimited stream of recorded commands, so if the canvas draws indefinitely without ever being cleared, at some point we have to rasterize the non-AA buffer just so that we can safely discard the recording data. Also, if at record time the necessary conditions for subpixel AA are not met, perhaps we just
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
For blending optimizations, it might be better to introduce a function instead of a boolean attribute like 'opaque'. What you really want, is to matte [1] the canvas with a solid color so you can optimize compositing. How about this API: void applyMatte(DOMString color); // color is a CSS rgb color value (alpha is ignored) When you call this function, the canvas is matted with that color. If it's the first drawing call, you can just fill the canvas with that color (no compositing needed) After matting, you no longer have to read or update the alpha channel since it's always 1 which should speed up drawing. 1: http://en.wikipedia.org/wiki/Matte_(filmmaking) On Wed, Feb 13, 2013 at 7:45 AM, Stephen White senorbla...@chromium.orgwrote: On Tue, Feb 12, 2013 at 6:14 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Feb 12, 2013 at 2:56 PM, Stephen White senorbla...@chromium.orgwrote: On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Jeremy Apthorp wrote: On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.org wrote: On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? Pixel-art style games. Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x). Do you have an example of a game where lines are drawn using a line API without antialiasing, then scaled up? Most pixel art games I've seen tend to use bitmaps for that kind of thing. On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? If LCD text were enable-able, authors would have to be mindful of a number of caveats in order to avoid rendering artifacts. Do we have any reason to believe the majority of authors would make the right decisions here? (The main reason we haven't provided control over things like antialiasing is that many authors tend to make terribly bad decisions.) (Before anyone gets offended, by the way: that you are reading this almost guarantees that you are above average in terms of authoring ability.) On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: We'd have to define what happens when you use subpixel antialiasing incorrectly, because we can be pretty sure authors will use it incorrectly and expect to get interoperable behavior. That's certainly true. Mozilla supports a mozOpaque attribute which makes the canvas buffer RGBX (initialized to solid black) and enables subpixel antialiasing for most text drawing. That might be enough to address your use-cases. I haven't specified this; if other vendors intend to implement this let me know and I can spec it. I'm not sure it's worth it though. [blowing the dust off this thread] Folks on the Chrome team are looking into implementing this attribute, and would be interested in seeing it spec'ed. What are you implementing? Initializing the canvas to black or subpixel antialiasing? We're interested in both aspects: the opportunity for culling and blending optimizations at composite time, as well as enabling subpixel AA. Stephen On Wed, 14 Nov 2012, Robert O'Callahan wrote: On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad ju...@chromium.org wrote: Are there precedents for exposing features with documented caveats? (excluding caveats that were discovered after the fact) Yes, and many of them have been extremely problematic, because Web authors will ignore the caveats. Right. I'd really like to avoid adding more if we can help it. On Wed, 14 Nov 2012, Justin Novosad wrote: There is a recent improvement in Chrome called deferred 2D canvas rendering (enabled by default as of Chrome 23). It is a mechanism that records 2d canvas commands during JS execution, and only executes them for real when the render buffer needs to be resolved (draw to screen, getImageData, toDataURL, etc.). If you want to check it out, the guts are in Skia: SkGPipe is a sort of FIFO for graphics
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier caban...@gmail.com wrote: For blending optimizations, it might be better to introduce a function instead of a boolean attribute like 'opaque'. What you really want, is to matte [1] the canvas with a solid color so you can optimize compositing. How about this API: void applyMatte(DOMString color); // color is a CSS rgb color value (alpha is ignored) When you call this function, the canvas is matted with that color. If it's the first drawing call, you can just fill the canvas with that color (no compositing needed) After matting, you no longer have to read or update the alpha channel since it's always 1 which should speed up drawing. Just to be sure we're on the same page, when I mentioned compositing optimizations, I was referring to compositing the canvas backing store into the page, not compositing operations within the canvas itself. One advantage of using an element attribute is that it could be used at backing store allocation time, to allocate RGB instead of RGBA. Forcing a reallocation of the backing store on attribute change would be consistent with changing width and height of the canvas, which have the same effect. Doing so on a context operation would not. If we did use a context function approach as you suggest, how would subpixel AA be handled? Would it be enabled on first call of the function and never disabled? Is there a way to query if the canvas is opaque once it's called? (I'm assuming that all changes to canvas alpha after the first call would have to be ignored, since otherwise you'd have to sniff every operation to see if it affected alpha, and reset the bit, although perhaps I'm misunderstanding your proposal.) Stephen
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Feb 13, 2013 at 11:25 AM, Stephen White senorbla...@chromium.orgwrote: On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier caban...@gmail.com wrote: For blending optimizations, it might be better to introduce a function instead of a boolean attribute like 'opaque'. What you really want, is to matte [1] the canvas with a solid color so you can optimize compositing. How about this API: void applyMatte(DOMString color); // color is a CSS rgb color value (alpha is ignored) When you call this function, the canvas is matted with that color. If it's the first drawing call, you can just fill the canvas with that color (no compositing needed) After matting, you no longer have to read or update the alpha channel since it's always 1 which should speed up drawing. Just to be sure we're on the same page, when I mentioned compositing optimizations, I was referring to compositing the canvas backing store into the page, not compositing operations within the canvas itself. sorry, I didn't mean to say blending. This is for optimizing compositing within the canvas and of the canvas into the page. One advantage of using an element attribute is that it could be used at backing store allocation time, to allocate RGB instead of RGBA. Forcing a reallocation of the backing store on attribute change would be consistent with changing width and height of the canvas, which have the same effect. Doing so on a context operation would not. why not? There is no reason for you to allocate the backing store until it's needed. The strange thing with an element attribute is that you can't change it back and it's also detached from the JS code that does the drawing. If we did use a context function approach as you suggest, how would subpixel AA be handled? Would it be enabled on first call of the function and never disabled? I did not think about subpixel AA. If I read the mozilla proposal correctly, they do AA if they know that the canvas is opaque. So, with my proposal, there would be no AA until you call 'applyMatte' (assuming you follow the mozilla way of doing AA). Is there a way to query if the canvas is opaque once it's called? Wouldn't the user know that he called 'applyMatte'? Also why do you want to query it? (I'm assuming that all changes to canvas alpha after the first call would have to be ignored, since otherwise you'd have to sniff every operation to see if it affected alpha, and reset the bit, although perhaps I'm misunderstanding your proposal.) No, you don't have to do that and can still use alpha. Simple alpha compositing is defined as follows [1] (in premultiplied alpha): co = cs + cb x (1 - αs) αo = αs + αb x (1 - αs) If you know that the backdrop is matted (αb = 1), the second formula always resolves to 1 so you can skip it. 1: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#porterduffcompositingoperators_srcover
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Feb 13, 2013 at 5:31 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Feb 13, 2013 at 11:25 AM, Stephen White senorbla...@chromium.org wrote: On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier caban...@gmail.com wrote: For blending optimizations, it might be better to introduce a function instead of a boolean attribute like 'opaque'. What you really want, is to matte [1] the canvas with a solid color so you can optimize compositing. How about this API: void applyMatte(DOMString color); // color is a CSS rgb color value (alpha is ignored) When you call this function, the canvas is matted with that color. If it's the first drawing call, you can just fill the canvas with that color (no compositing needed) After matting, you no longer have to read or update the alpha channel since it's always 1 which should speed up drawing. Just to be sure we're on the same page, when I mentioned compositing optimizations, I was referring to compositing the canvas backing store into the page, not compositing operations within the canvas itself. sorry, I didn't mean to say blending. This is for optimizing compositing within the canvas and of the canvas into the page. One advantage of using an element attribute is that it could be used at backing store allocation time, to allocate RGB instead of RGBA. Forcing a reallocation of the backing store on attribute change would be consistent with changing width and height of the canvas, which have the same effect. Doing so on a context operation would not. why not? There is no reason for you to allocate the backing store until it's needed. True. I was just trying to understand when you would use this function more than once during canvas lifetime. Presumably, that's the reason for having a function, no? If so, and you don't maintain any special state about the opacity of the canvas, how is this different from an rgb() fillRect()? The strange thing with an element attribute is that you can't change it back and it's also detached from the JS code that does the drawing. You can change it back programmatically through the DOM, as you can with the element width and height. If we did use a context function approach as you suggest, how would subpixel AA be handled? Would it be enabled on first call of the function and never disabled? I did not think about subpixel AA. If I read the mozilla proposal correctly, they do AA if they know that the canvas is opaque. So, with my proposal, there would be no AA until you call 'applyMatte' (assuming you follow the mozilla way of doing AA). OK, so there would have to be a bit of state saved at that point, in order to know if subpixel AA is allowable? At any rate, I don't think this works if you subsequently modify the canvas's alpha (see below). Is there a way to query if the canvas is opaque once it's called? Wouldn't the user know that he called 'applyMatte'? Also why do you want to query it? (I'm assuming that all changes to canvas alpha after the first call would have to be ignored, since otherwise you'd have to sniff every operation to see if it affected alpha, and reset the bit, although perhaps I'm misunderstanding your proposal.) No, you don't have to do that and can still use alpha. Simple alpha compositing is defined as follows [1] (in premultiplied alpha): co = cs + cb x (1 - αs) αo = αs + αb x (1 - αs) If you know that the backdrop is matted (αb = 1), the second formula always resolves to 1 so you can skip it. The problem is, canvas supports more than simple (source-over) compositing, so there are ways of modifying the destination alpha back to non-1, e.g., a primitive with non-1 alpha drawn with source-copy, or via putImageData(). At that point, the state of the canvas's alpha is unknown, so the page compositor can make no assumptions about its opacity. Stephen
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 12:39 PM, Stephen White senorbla...@chromium.orgwrote: On Wed, Feb 13, 2013 at 5:31 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, Feb 13, 2013 at 11:25 AM, Stephen White senorbla...@chromium.org wrote: On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier caban...@gmail.com wrote: For blending optimizations, it might be better to introduce a function instead of a boolean attribute like 'opaque'. What you really want, is to matte [1] the canvas with a solid color so you can optimize compositing. How about this API: void applyMatte(DOMString color); // color is a CSS rgb color value (alpha is ignored) When you call this function, the canvas is matted with that color. If it's the first drawing call, you can just fill the canvas with that color (no compositing needed) After matting, you no longer have to read or update the alpha channel since it's always 1 which should speed up drawing. Just to be sure we're on the same page, when I mentioned compositing optimizations, I was referring to compositing the canvas backing store into the page, not compositing operations within the canvas itself. sorry, I didn't mean to say blending. This is for optimizing compositing within the canvas and of the canvas into the page. One advantage of using an element attribute is that it could be used at backing store allocation time, to allocate RGB instead of RGBA. Forcing a reallocation of the backing store on attribute change would be consistent with changing width and height of the canvas, which have the same effect. Doing so on a context operation would not. why not? There is no reason for you to allocate the backing store until it's needed. True. I was just trying to understand when you would use this function more than once during canvas lifetime. Presumably, that's the reason for having a function, no? You would need it again if you draw with a compositing mode that removes alpha (like 'copy') If so, and you don't maintain any special state about the opacity of the canvas, how is this different from an rgb() fillRect()? pretty much the same except - ignore alpha - use destination-over - automatically fills the whole canvas The strange thing with an element attribute is that you can't change it back and it's also detached from the JS code that does the drawing. You can change it back programmatically through the DOM, as you can with the element width and height. But would it do something when you set it back? How would you know what part was painted black or originally transparent? If we did use a context function approach as you suggest, how would subpixel AA be handled? Would it be enabled on first call of the function and never disabled? I did not think about subpixel AA. If I read the mozilla proposal correctly, they do AA if they know that the canvas is opaque. So, with my proposal, there would be no AA until you call 'applyMatte' (assuming you follow the mozilla way of doing AA). OK, so there would have to be a bit of state saved at that point, in order to know if subpixel AA is allowable? Yes. It would be an optimisation under the hood that an advanced user can use. At any rate, I don't think this works if you subsequently modify the canvas's alpha (see below). Is there a way to query if the canvas is opaque once it's called? Wouldn't the user know that he called 'applyMatte'? Also why do you want to query it? (I'm assuming that all changes to canvas alpha after the first call would have to be ignored, since otherwise you'd have to sniff every operation to see if it affected alpha, and reset the bit, although perhaps I'm misunderstanding your proposal.) No, you don't have to do that and can still use alpha. Simple alpha compositing is defined as follows [1] (in premultiplied alpha): co = cs + cb x (1 - αs) αo = αs + αb x (1 - αs) If you know that the backdrop is matted (αb = 1), the second formula always resolves to 1 so you can skip it. The problem is, canvas supports more than simple (source-over) compositing, so there are ways of modifying the destination alpha back to non-1, e.g., a primitive with non-1 alpha drawn with source-copy, or via putImageData(). At that point, the state of the canvas's alpha is unknown, so the page compositor can make no assumptions about its opacity. What would happen if you set 'opaque' to true and you draw with alpha and 'copy' compositing? It seems that that has the same issue (unless you're OK with breaking drawing).
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier caban...@gmail.com wrote: What would happen if you set 'opaque' to true and you draw with alpha and 'copy' compositing? It seems that that has the same issue (unless you're OK with breaking drawing). The alpha values of all moz-opaque canvas pixels are simply not affected by compositing. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier caban...@gmail.com wrote: What would happen if you set 'opaque' to true and you draw with alpha and 'copy' compositing? It seems that that has the same issue (unless you're OK with breaking drawing). The alpha values of all moz-opaque canvas pixels are simply not affected by compositing. Exactly! So, this will break drawing as the pixels with no alpha will be black with no way to undo that.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier caban...@gmail.com wrote: On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier caban...@gmail.com wrote: What would happen if you set 'opaque' to true and you draw with alpha and 'copy' compositing? It seems that that has the same issue (unless you're OK with breaking drawing). The alpha values of all moz-opaque canvas pixels are simply not affected by compositing. Exactly! So, this will break drawing as the pixels with no alpha will be black with no way to undo that. I don't know what you mean by no way to undo that or break drawing. 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 2:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 4:18 PM, Rik Cabanier caban...@gmail.com wrote: On Thu, Feb 14, 2013 at 2:12 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 3:55 PM, Rik Cabanier caban...@gmail.comwrote: What would happen if you set 'opaque' to true and you draw with alpha and 'copy' compositing? It seems that that has the same issue (unless you're OK with breaking drawing). The alpha values of all moz-opaque canvas pixels are simply not affected by compositing. Exactly! So, this will break drawing as the pixels with no alpha will be black with no way to undo that. I don't know what you mean by no way to undo that or break drawing. My proposal doesn't change anything for the user as it has no side effects (apart from faster drawing when possible). Setting 'opaque' on the canvas actually changes how compositing works. For instance, if you use 'copy' compositing with a partially transparent image, you will draw black pixels where the image has no coverage. In addition, partially transparent pixels will look darker the more transparent they are. Looking at the WebKit implementation, I'm unsure how 'opaque' can implemented for accelerated canvas. It might work with non-accelerated canvas but would have to run some experiments. I also look at mozilla's Core Graphics implementation and unless I'm missing something, it doesn't have special code to handle 'opaque'. When do you use this parameter?
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier caban...@gmail.com wrote: Looking at the WebKit implementation, I'm unsure how 'opaque' can implemented for accelerated canvas. It might work with non-accelerated canvas but would have to run some experiments. I also look at mozilla's Core Graphics implementation and unless I'm missing something, it doesn't have special code to handle 'opaque'. When do you use this parameter? CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That selects a surface format that is passed down to the graphics layer when creating the canvas surface. It's true that we don't currently do anything with that when drawing with CoreGraphics. That would need to be cleaned up before we started promoting this feature. Now that you mention it, having to modify the definition of compositing is a bit of a bummer for the 'opaque' attribute approach. I think we could do everything we want using your approach --- internally keeping a flag to indicate whether the alpha values of the canvas are all 1, setting it when the canvas is filled with a solid color and clearing it when non-over drawing (or clear()) are used. Let's try that! But I think matte is unnecessarily obscure. How about adding a clear(DOMString) method that does a 'copy' of the color to the entire canvas buffer? The color could default to rgba(0,0,0,0). 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]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 3:35 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 5:16 PM, Rik Cabanier caban...@gmail.com wrote: Looking at the WebKit implementation, I'm unsure how 'opaque' can implemented for accelerated canvas. It might work with non-accelerated canvas but would have to run some experiments. I also look at mozilla's Core Graphics implementation and unless I'm missing something, it doesn't have special code to handle 'opaque'. When do you use this parameter? CanvasRenderingContext2D::GetSurfaceFormat is part of the process. That selects a surface format that is passed down to the graphics layer when creating the canvas surface. It's true that we don't currently do anything with that when drawing with CoreGraphics. That would need to be cleaned up before we started promoting this feature. Now that you mention it, having to modify the definition of compositing is a bit of a bummer for the 'opaque' attribute approach. I think we could do everything we want using your approach --- internally keeping a flag to indicate whether the alpha values of the canvas are all 1, setting it when the canvas is filled with a solid color and clearing it when non-over drawing (or clear()) are used. Let's try that! But I think matte is unnecessarily obscure. How about adding a clear(DOMString) method that does a 'copy' of the color to the entire canvas buffer? The color could default to rgba(0,0,0,0). Yes, that would work. Drawbacks are: - you can't draw onto a transparent backdrop and apply matting. - if you use a compositing mode that changes the canvas alpha to something else than 1, you can't optimize the drawing any more. Both these are caused because 'clear' removes the canvas content.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Jeremy Apthorp wrote: On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.org wrote: On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? Pixel-art style games. Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x). Do you have an example of a game where lines are drawn using a line API without antialiasing, then scaled up? Most pixel art games I've seen tend to use bitmaps for that kind of thing. On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? If LCD text were enable-able, authors would have to be mindful of a number of caveats in order to avoid rendering artifacts. Do we have any reason to believe the majority of authors would make the right decisions here? (The main reason we haven't provided control over things like antialiasing is that many authors tend to make terribly bad decisions.) (Before anyone gets offended, by the way: that you are reading this almost guarantees that you are above average in terms of authoring ability.) On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: We'd have to define what happens when you use subpixel antialiasing incorrectly, because we can be pretty sure authors will use it incorrectly and expect to get interoperable behavior. That's certainly true. Mozilla supports a mozOpaque attribute which makes the canvas buffer RGBX (initialized to solid black) and enables subpixel antialiasing for most text drawing. That might be enough to address your use-cases. I haven't specified this; if other vendors intend to implement this let me know and I can spec it. I'm not sure it's worth it though. [blowing the dust off this thread] Folks on the Chrome team are looking into implementing this attribute, and would be interested in seeing it spec'ed. Thanks, Stephen On Wed, 14 Nov 2012, Robert O'Callahan wrote: On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad ju...@chromium.org wrote: Are there precedents for exposing features with documented caveats? (excluding caveats that were discovered after the fact) Yes, and many of them have been extremely problematic, because Web authors will ignore the caveats. Right. I'd really like to avoid adding more if we can help it. On Wed, 14 Nov 2012, Justin Novosad wrote: There is a recent improvement in Chrome called deferred 2D canvas rendering (enabled by default as of Chrome 23). It is a mechanism that records 2d canvas commands during JS execution, and only executes them for real when the render buffer needs to be resolved (draw to screen, getImageData, toDataURL, etc.). If you want to check it out, the guts are in Skia: SkGPipe is a sort of FIFO for graphics commands, SkDeferredCanvas is a wrapper that manages the GPipe and automatically flushes it and applies some command culling optimizations. So to come back to the problem of with and without subpixel AA buffers: if rendering is deferred, the non-AA buffer would never get rasterized (and possibly never even allocated), unless it needs to be. Obviously there are practical limitations, for example we cannot store an unlimited stream of recorded commands, so if the canvas draws indefinitely without ever being cleared, at some point we have to rasterize the non-AA buffer just so that we can safely discard the recording data. Also, if at record time the necessary conditions for subpixel AA are not met, perhaps we just forget about it. I admit this is a complex solution for implementors, but it makes the management of subpixel-AA safety transparent to web authors. I think it'd be reasonable (for some definition of reasonable that relates to whether it's compatible with the spec, anyway) for implementors to do this today, without having to expose any control to the author. On Thu, 15 Nov 2012, Fred Andrews wrote: The canvas that scripts draw into could be over-sized with the UA down sampling
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Tue, Feb 12, 2013 at 2:56 PM, Stephen White senorbla...@chromium.orgwrote: On Fri, Nov 23, 2012 at 6:04 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Jeremy Apthorp wrote: On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.org wrote: On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? Pixel-art style games. Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x). Do you have an example of a game where lines are drawn using a line API without antialiasing, then scaled up? Most pixel art games I've seen tend to use bitmaps for that kind of thing. On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? If LCD text were enable-able, authors would have to be mindful of a number of caveats in order to avoid rendering artifacts. Do we have any reason to believe the majority of authors would make the right decisions here? (The main reason we haven't provided control over things like antialiasing is that many authors tend to make terribly bad decisions.) (Before anyone gets offended, by the way: that you are reading this almost guarantees that you are above average in terms of authoring ability.) On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: We'd have to define what happens when you use subpixel antialiasing incorrectly, because we can be pretty sure authors will use it incorrectly and expect to get interoperable behavior. That's certainly true. Mozilla supports a mozOpaque attribute which makes the canvas buffer RGBX (initialized to solid black) and enables subpixel antialiasing for most text drawing. That might be enough to address your use-cases. I haven't specified this; if other vendors intend to implement this let me know and I can spec it. I'm not sure it's worth it though. [blowing the dust off this thread] Folks on the Chrome team are looking into implementing this attribute, and would be interested in seeing it spec'ed. What are you implementing? Initializing the canvas to black or subpixel antialiasing? On Wed, 14 Nov 2012, Robert O'Callahan wrote: On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad ju...@chromium.org wrote: Are there precedents for exposing features with documented caveats? (excluding caveats that were discovered after the fact) Yes, and many of them have been extremely problematic, because Web authors will ignore the caveats. Right. I'd really like to avoid adding more if we can help it. On Wed, 14 Nov 2012, Justin Novosad wrote: There is a recent improvement in Chrome called deferred 2D canvas rendering (enabled by default as of Chrome 23). It is a mechanism that records 2d canvas commands during JS execution, and only executes them for real when the render buffer needs to be resolved (draw to screen, getImageData, toDataURL, etc.). If you want to check it out, the guts are in Skia: SkGPipe is a sort of FIFO for graphics commands, SkDeferredCanvas is a wrapper that manages the GPipe and automatically flushes it and applies some command culling optimizations. So to come back to the problem of with and without subpixel AA buffers: if rendering is deferred, the non-AA buffer would never get rasterized (and possibly never even allocated), unless it needs to be. Obviously there are practical limitations, for example we cannot store an unlimited stream of recorded commands, so if the canvas draws indefinitely without ever being cleared, at some point we have to rasterize the non-AA buffer just so that we can safely discard the recording data. Also, if at record time the necessary conditions for subpixel AA are not met, perhaps we just forget about it. I admit this is a complex solution for implementors, but it makes the management of subpixel-AA safety transparent to web authors. I think it'd be reasonable (for some definition of reasonable that relates to
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
It's hard to analyze your use-case without knowing what it is. For some kinds of large data model applications, I can think of DOM-based implementation techniques that might be a lot more performant than those you have mentioned. I agree that this is a very challenging domain. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Nov 24, 2012 at 7:10 PM, Adam Barth w...@adambarth.com wrote: 2) Remarkably, the current best candidate is a rendering pipeline that attempts to use the DOM in immediate mode. The application performs some application-specific processing to determine which portions of the model can actually affect what's drawn on screen, and then the application uses innerHTML to create DOM for that portion of the model. (They've experimented with a bunch of choices and innerHTML appears to be the fastest way to use the DOM as an immediate mode API.) Using this pipeline, the application uses reasonable amounts of memory and hit testing, etc, aren't impacted. This pipeline gets about 20 fps. I'm working on ways to make this process easier and more performant, first on the CSS side, then on the DOM side. Right now it's internal, but as soon as I have something that's not crap, I'll be posting it here for review, feedback, and iteration. My current plan is: * On the CSS side, provide some nice new primitives for isolating layout of elements, so that you can be sure that your DOM-tweaking won't break out and cause unexpected reflow in the rest of the document. That's a perf-killer. Connected to that, provide a way to guarantee that an element's rendering doesn't extend outside of itself (or a bounds around itself), so that we can, behind the scenes, destroy renderers that are off-screen and which we predict won't be viewed again in the near future. * On the DOM side, at the lowest level, provide some primitives that do the ugly grunt-work that people are already doing in JS (prediction of the area that is visible and which is soon-to-be-visible), and hopefully neuter some related problems of very large lists as well (such as simply running out of coordinate space - it appears that you start hitting problems when an element exceeds 1M-16M (varies by browser) pixels in one dimension). Building atop that, some convenient declarative tools that take even more of the work out of the author's hands and let us do more stuff automatically and with higher performance: for example, perhaps the author can just provide a JS array of data and a template element, and the browser generates and destroys DOM on the fly from this. ~TJ
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? The metrics I've seen show that the magnitude of this problem is approximately 8x (to the extent that it's sensible to represent the magnitude with a number). As far as I can tell, the issue really boils down to the DOM being retained mode and canvas being immediate mode. As the size of the underlying model grows, uploading the entire model into the DOM becomes increasingly uncompetitive with having the application manage the model and drawing using immediate mode because the application can use application-specific knowledge to avoid having to process large portions of the model. I'm unsure what details I'm able to share about these experiments. Justin might know better what we're able to share, but the outcomes are roughly: 1) Uploading the entire document model into DOM (say for a model that requires 1 million elements to represent) causes the application to become completely unusable. Memory consumption goes off the charts, hit testing noticeably lags, etc. We've been working to improve performance here, but there are limits to what we'll be able to achieve. For example, DOM is always going to be a less memory efficient than an application-specific representation. On some rendering benchmarks, a variety of browsers are able to render these models at about 8 fps. 2) Remarkably, the current best candidate is a rendering pipeline that attempts to use the DOM in immediate mode. The application performs some application-specific processing to determine which portions of the model can actually affect what's drawn on screen, and then the application uses innerHTML to create DOM for that portion of the model. (They've experimented with a bunch of choices and innerHTML appears to be the fastest way to use the DOM as an immediate mode API.) Using this pipeline, the application uses reasonable amounts of memory and hit testing, etc, aren't impacted. This pipeline gets about 20 fps. 3) Once they've moved from (1) to (2), you can understand why the next logical step is to use a real immediate mode API, like canvas or WebGL. Approach (2) is totally nutty: there's no way the right design is to build up a giant string of markup and then run it through the parser for every frame. Using canvas, the application has no trouble achieving 60 fps. I think the real question here is how do we want applications with very large models to render? Do we really want them to upload their entire models into DOM? If not, how can we provide them with a high-quality immediate model rendering pipeline. Adam
[whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, 29 Mar 2012, Jeremy Apthorp wrote: On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp jere...@chromium.orgwrote: On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? Pixel-art style games. Specifically: even with the new image smoothing stuff in place for drawImage, a 1:2 diagonal line will still be anti-aliased (only the antialiasing will look silly scaled up to 2x). Do you have an example of a game where lines are drawn using a line API without antialiasing, then scaled up? Most pixel art games I've seen tend to use bitmaps for that kind of thing. On Mon, 12 Nov 2012, Justin Novosad wrote: For many types of apps, DOM-based rendering is uncompetitively slow [so we should make text rendering in canvas more controllable] This seems like something we should fix, not something we should work around by having people use canvas instead. Using canvas has all kinds of terrible side-effects, like reducing the likely accessibility of the page, making searcheability much worse, etc. Also, do you have any metrics showing the magnitude of this problem on real-world sites that might consider using canvas instead? If LCD text were enable-able, authors would have to be mindful of a number of caveats in order to avoid rendering artifacts. Do we have any reason to believe the majority of authors would make the right decisions here? (The main reason we haven't provided control over things like antialiasing is that many authors tend to make terribly bad decisions.) (Before anyone gets offended, by the way: that you are reading this almost guarantees that you are above average in terms of authoring ability.) On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote: We'd have to define what happens when you use subpixel antialiasing incorrectly, because we can be pretty sure authors will use it incorrectly and expect to get interoperable behavior. That's certainly true. Mozilla supports a mozOpaque attribute which makes the canvas buffer RGBX (initialized to solid black) and enables subpixel antialiasing for most text drawing. That might be enough to address your use-cases. I haven't specified this; if other vendors intend to implement this let me know and I can spec it. I'm not sure it's worth it though. On Wed, 14 Nov 2012, Robert O'Callahan wrote: On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad ju...@chromium.org wrote: Are there precedents for exposing features with documented caveats? (excluding caveats that were discovered after the fact) Yes, and many of them have been extremely problematic, because Web authors will ignore the caveats. Right. I'd really like to avoid adding more if we can help it. On Wed, 14 Nov 2012, Justin Novosad wrote: There is a recent improvement in Chrome called deferred 2D canvas rendering (enabled by default as of Chrome 23). It is a mechanism that records 2d canvas commands during JS execution, and only executes them for real when the render buffer needs to be resolved (draw to screen, getImageData, toDataURL, etc.). If you want to check it out, the guts are in Skia: SkGPipe is a sort of FIFO for graphics commands, SkDeferredCanvas is a wrapper that manages the GPipe and automatically flushes it and applies some command culling optimizations. So to come back to the problem of with and without subpixel AA buffers: if rendering is deferred, the non-AA buffer would never get rasterized (and possibly never even allocated), unless it needs to be. Obviously there are practical limitations, for example we cannot store an unlimited stream of recorded commands, so if the canvas draws indefinitely without ever being cleared, at some point we have to rasterize the non-AA buffer just so that we can safely discard the recording data. Also, if at record time the necessary conditions for subpixel AA are not met, perhaps we just forget about it. I admit this is a complex solution for implementors, but it makes the management of subpixel-AA safety transparent to web authors. I think it'd be reasonable (for some definition of reasonable that relates to whether it's compatible with the spec, anyway) for implementors to do this today, without having to expose any control to the author. On Thu, 15 Nov 2012, Fred Andrews wrote: The canvas that scripts draw into could be over-sized with the UA down sampling this to fit the target size and taking into account the sub-pixel screen layout when doing so. On Thu, 15 Nov 2012, Justin Novosad wrote: Obviously, that would be costly (x3 pixels), but I think it is a very realistic solution and relatively low hanging fruit. The over-sizing
