Add shapeSmoothingEnabled option for CanvasRenderingContext2D #9192

nornagon · 2023-04-20T21:03:07Z

At least two implementers are interested (and none opposed):
- Chromium
- …
Tests are written and can be reviewed and commented upon at:
- Add test for CanvasRenderingContext2D.shapeSmoothingEnabled web-platform-tests/wpt#39633
Implementation bugs are filed:
- Chromium: …
- Gecko: …
- WebKit: …
MDN issue is filed: …

(See WHATWG Working Mode: Changes for more details.)

/acknowledgements.html ( diff )
/canvas.html ( diff )
/index.html ( diff )

Kaiido

Thank you very much for getting this moving.

Not an exhaustive review yet, and definitely not authoritative, but I wonder if this would need some deeper definition.
For instance we could hook into the fill and stroke steps. This might be the occasion to finally define the fill algorithm that they both do call (see #8145). But maybe this could be handled in a follow-up PR if that's too much work.

Another thing that might require discussion: it's relatively unclear if this should affect clip() or not.

cc @whatwg/canvas

Kaiido · 2023-04-21T02:27:33Z

source

+
+   <dd>
+    <p>Returns whether the fill and stroke of paths should be smoothed ("anti-aliased") when drawn,
+    if their pixels don't line up exactly with the display.</p>


My build complained about "may" -> "can".

I'm not quite sure why that would be? This line has neither of those words...

My review got completely mixed up by github with a prior one I started against the first commit, so all the line numbers are wrong, sorry. It used to be correct on the "files changed" tab but isn't anymore.
Anyway, the "may" in question is at line 68211

the user agent may choose to fill [...]

Kaiido · 2023-04-21T03:05:39Z

source

+  <div w-nodev>
+
+  <p>Objects that implement the <code>CanvasShapeSmoothing</code> interface have attributes that
+  control how shape smoothing is performed.</p>


The expression "shape smoothing" seems a bit vague here. Maybe it's best we talk about "rendering" in the authoritative parts? "Smoothing" could also refer to the act of converting angles to curves. To be clear, I still think "shapeSmoothinEnabled" is the right name for the method given imageSmoothingEnabled, it's really just here that I might prefer something clearer.

Makes sense. How about:

Suggested change

control how shape smoothing is performed.</p>

control how shape rasterization is performed.</p>

as this is really about the conversion of the shape into pixels?

Yes sounds better to me. Hopefully one day we'd have a formal step by step algo where this would fit in. But for now that might do.

Kaiido · 2023-04-21T03:15:30Z

source

+    <p>When false, the user agent may choose to fill and stroke paths without smoothing
+    ("anti-aliasing").</p>
+
+    <p>Can be set, to change whether filled and stroked paths are smoothed (true) or, at the


"at the discretion of ..." sounds a bit funny. What about we call it a "hint" directly?
Maybe something along

Can be set, to hint to the user agent whether filled and stroked paths should be smoothed (true), or not (false).

"at the discretion of" follows the language in CanvasFontKerning, though I don't see that language anywhere else. I'm happy to follow your suggestion, though :)

junov · 2023-04-21T14:48:36Z

source

+   <dt><code data-x=""><var>context</var>.<span subdfn data-x="dom-context-2d-shapeSmoothingEnabled">shapeSmoothingEnabled</span> [ = <var>value</var> ]</code></dt>
+
+   <dd>
+    <p>When false, the user agent may choose to fill and stroke paths without smoothing


I support the idea that this option should be a hint, since UAs are not require to implement any form of anti-aliasing, but I think the wording should be imperative when it comes to disabling anti-aliasing since there are important use cases that require anti-aliasing to be disabled. In particular, the use case of drawing meshes without seams requires AA to be disabled. This has been a long-standing source of pain for developers who've been forced to limit their apps to use pixel-aligned rects, or switch to WebGL.

If this attribute were an enum instead of a bool, the "imperativeness" and "hint-ness" of the option could be implied in the names of the options in the enum. For example, the options could be "default" and "pixelated".

Based on past feature requests, I know many developers would want this option to apply to drawImage(), and IMHO it should also apply to fillRect and strokeRect, for consistency.

I agree this should also apply to strokeRect() and fillRect(), and I believe that if we do hook to the currently undefined fill operation I talked about in my previous comment we'd get them all in one place.

However I'm a bit curious about this drawImage() idea. How would that cohabit with imageSmoothing[Enabled|Quality]? Would one overrule the other? Based on what?

As for the attribute being an enum directly, I personally have no strong opinion, it came like that as a kind of symmetry with the existing imageSmoothing[...] attributes, but it's true that it's not necessary we follow this path. In that case we could also choose to get closer to SVG and their shape-rendering attribute.

I don't think this option should affect image smoothing, as @Kaiido says we already have imageSmoothingEnabled for that.

As for hintness, it seems like @junov is suggesting we flip the optionality here, to make drawing shapes with AA be optional when shapeSmoothingEnabled = true, but drawing shapes without AA be required when shapeSmoothingEnabled = false.

I agree with @junov that this is can be important for maintaining authorial intent. The initial suggestion to phrase this as a hint to the UA was from @mysteryDate here. SVG's shape-rendering attribute is also phrased as a hint.

My feeling is that phrasing shape smoothing as a hint is okay; there are several other properties of canvas that clearly convey authorial intent but are phrased as a "hint" in the spec. I don't see this one as being particularly different.

As for getting closer to SVG's shape-rendering, that seems not unreasonable. I'm not really sure what the difference here between crispEdges and optimizeSpeed is supposed to be, but it looks like Chromium treats them the same (both meaning "do not anti-alias"). I don't think I have enough domain expertise here to know if this is needless complexity or clever future-proofing. Perhaps @mysteryDate could weigh in?

junov · 2023-04-21T14:50:43Z

source

@@ -63139,6 +63140,11 @@ interface mixin <dfn interface>CanvasImageSmoothing</dfn> {
 -->
 };

+interface mixin <dfn interface>CanvasShapeSmoothing</dfn> {
+  // shape smoothing
+  attribute boolean <span data-x="dom-context-2d-shapeSmoothingEnabled">shapeSmoothingEnabled</span>; // (default true)


Let's not repeat the mistake of imageSmoothingEnabled. Please make this attribute an enum and just call it "shapeSmoothing" so that it can be extended in the future if necessary.

FWIW, future extension of this feature might include:

controlling qualitiy vs performance tradeoffs (number of MSAA samples, choice of analytical AA algorithm, etc.)

disallowing subpixel AA to avoid artifacts when images are re-scaled or composited

If we go in the enum direction I'm inclined to follow SVG's shape-rendering, e.g.

enum ShapeRenderingValue { "auto", "optimizeSpeed", "crispEdges", "geometricPrecision" } interface mixin CanvasShapeRendering { attribute ShapeRenderingValue shapeRendering; // (default "auto") }

How would you imagine those future extensions would be added? As additional options in the enum?

junov

Thanks for helping to move this forward.

junov · 2023-04-21T14:56:28Z

source

+   <dt><code data-x=""><var>context</var>.<span subdfn data-x="dom-context-2d-shapeSmoothingEnabled">shapeSmoothingEnabled</span> [ = <var>value</var> ]</code></dt>
+
+   <dd>
+    <p>When false, the user agent may choose to fill and stroke paths without smoothing


If this attribute were an enum instead of a bool, the "imperativeness" and "hint-ness" of the option could be implied in the names of the options in the enum. For example, the options could be "default" and "pixelated".

junov · 2023-04-21T14:59:38Z

source

+   <dt><code data-x=""><var>context</var>.<span subdfn data-x="dom-context-2d-shapeSmoothingEnabled">shapeSmoothingEnabled</span> [ = <var>value</var> ]</code></dt>
+
+   <dd>
+    <p>When false, the user agent may choose to fill and stroke paths without smoothing


Based on past feature requests, I know many developers would want this option to apply to drawImage(), and IMHO it should also apply to fillRect and strokeRect, for consistency.

junov · 2023-04-21T15:11:42Z

source

@@ -63139,6 +63140,11 @@ interface mixin <dfn interface>CanvasImageSmoothing</dfn> {
 -->
 };

+interface mixin <dfn interface>CanvasShapeSmoothing</dfn> {
+  // shape smoothing
+  attribute boolean <span data-x="dom-context-2d-shapeSmoothingEnabled">shapeSmoothingEnabled</span>; // (default true)


FWIW, future extension of this feature might include:

controlling qualitiy vs performance tradeoffs (number of MSAA samples, choice of analytical AA algorithm, etc.)

disallowing subpixel AA to avoid artifacts when images are re-scaled or composited

nornagon · 2023-04-24T20:07:32Z

@Kaiido I think it would make sense to mention this property in a more formal description of the fill algorithm, but I don't think this change should be blocked on that.

Kaiido · 2023-04-28T03:53:13Z

I did play a bit with the currently proposed chromium patch, and I believe a few more Path2D consumers should be affected.

As I presumed, it's a bit surprising at use that clip() isn't, and while one could manage something doing manually compositing + fill(), I believe it would be better for clip() to use that rule directly.

Then, it doesn't affect isPointInPath() and isPointInStroke() either. Here I'm quite convinced that it should. Otherwise we could end up in situations like this, which in the current chromium CL does say that the red pixel is not in the path, when visually it clearly is.

nornagon added 3 commits April 20, 2023 13:58

Add shapeSmoothingEnabled option for CanvasRenderingContext2D

44cb0e1

Fixes whatwg#3181

fix markup

7784c71

language about UA hint

a88ec38

nornagon mentioned this pull request Apr 20, 2023

Drawing crisp lines in canvas #3181

Open

add name to ACKS

604d0e7

nornagon mentioned this pull request Apr 20, 2023

Add test for CanvasRenderingContext2D.shapeSmoothingEnabled web-platform-tests/wpt#39633

Open

Kaiido reviewed Apr 21, 2023

View reviewed changes

Kaiido added the topic: canvas label Apr 21, 2023

junov reviewed Apr 21, 2023

View reviewed changes

Maxdamantus mentioned this pull request Apr 12, 2024

Apple animation visual bug Maxdamantus/recplay#5

Closed

	control how shape smoothing is performed.</p>
	control how shape rasterization is performed.</p>

Add shapeSmoothingEnabled option for CanvasRenderingContext2D #9192

Are you sure you want to change the base?

Add shapeSmoothingEnabled option for CanvasRenderingContext2D #9192

Conversation

nornagon commented Apr 20, 2023 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kaiido left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

junov Apr 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

junov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nornagon commented Apr 24, 2023

Uh oh!

Kaiido commented Apr 28, 2023

Uh oh!

Uh oh!

nornagon commented Apr 20, 2023 •

edited by pr-preview bot

Loading

Kaiido left a comment •

edited

Loading

junov Apr 21, 2023 •

edited

Loading