Add a layer and filter interface in the 2D canvas #9537

graveljp · 2023-07-19T19:49:25Z

This adds new beginLayer and endLayer functions to open and close layers
in the canvas. While layers are active, draw calls operate on a separate
texture that gets composited to the parent output bitmap when the layer
is closed. An optional filter can be specified in beginLayer, allowing
effects to be applied to the layer's texture when it's composited its
parent.

Fixes #8476

At least two implementers are interested (and none opposed):
- Chromium
- Gecko
- WebKit
Tests are written and can be reviewed and commented upon at:
- https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/layers
- https://github.com/web-platform-tests/wpt/tree/master/html/canvas/offscreen/layers
Implementation bugs are filed:
- Chromium: crbug.com/1396372
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1866551
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=259494
MDN issue is filed: …

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

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

Kaiido

Impressive work on this.
I still have some concerns about the layer rendering state being picked from the global settings instead of being defined along the filter as a parameter, and about the "when a canvas is presented" concept, but otherwise it all seems to make sense, I think.

Also, I've been a bit quick over the CanvasFilters part as I suppose it's mostly what had already been reviewed on #6763 by Aaron.

source

Kaiido · 2023-07-24T01:56:08Z

source

+  has one, is always just an alias to a <code>canvas</code> element's bitmap. When layers are
+  opened, implementations must behave as if draw calls operate on a separate <span>output
+  bitmap</span> that gets composited to the parent <span>output bitmap</span> when the layer is
+  closed. If the <code>canvas</code> element's bitmap needs to be presented while layers are opened,


"presented" is unfortunately a bit unclear as a concept, should it be clearly defined?

I agree, this has actually caused me some confusion as I was trying to understand how the canvas gets consumed by the event loop. I added a "concept-canvas-presented" definition above to clarify this.

Great.
Hopefully if/when the "update the rendering" steps are rewritten to finally match the implementations we'll be able to add a line about that in there too?
My only remaining concern about this would be about other canvas consumers that don't go through the "check the usability of the image" algo. On the top of my head I can only think of the mediacapture-fromelement (canvas.captureStream()), where they never defined when the canvas frame should be moved to the stream.
I guess having this definition would help them to specify the apparent implementation which seems to be to wait for the next "update the rendering". (c.f. w3c/mediacapture-fromelement#94 and linked).

source

Kaiido · 2023-07-24T03:26:35Z

source

+
+  <div w-nodev>
+
+  <p>Before any operations could access the <code>canvas</code> element's bitmap pixels, the


Given that reading operations do throw if a layer is open, this leaves only the ill-defined "when the canvas is presented" case that could reach it, right?

That was the intent. But I removed this section. The CanvasRenderingContext2D now has a top level output bitmap and a current output bitmap. The top level output bitmap can always be presented to the user even when layers are opened. When layers are opened, draw operations are performed in a separate bitmap via current output bitmap.

Kaiido · 2023-07-24T03:33:19Z

source

+  was flushed by running the steps for <dfn>restoring the drawing state stack</dfn>:</p>
+
+  <ol>
+   <li><p><span data-x="list iterate">For each</span> <var>stateEntry</var> of
+   <var>stateBackup</var>:</p></li>
+
+   <ol>
+    <li><p><span data-x="stack push">Push</span> <var>stateEntry</var> onto the <span>drawing state
+    stack</span>.</p></li>
+   </ol>
+
+   <li><p>Restore the context's current <span>drawing state</span> by running the <code
+   data-x="dom-context-2d-restore">restore()</code> method steps.</p></li>


So this doesn't restore any of the bitmaps, right? This means that if we have something like

ctx.globalAlpha = 0.2; ctx.beginLayer(); ctx.fillRect(0, 0, 50, 50);

The rectangle will keep getting more opaque every time the canvas is "presented". Which is... every frame while it's visible on the page? Or every time the page has to be repainted? Or something else?

This section has been removed.

The idea was that when presenting a frame, all the layers would have been closed, the draw calls would have been rasterized, and then, all layers would have been re-opened. This algorithm was describing the logic for re-opening the layers. Only the states were to be re-populated, not the draw calls. On later frame, only new draw calls would get drawn.

This was all replaced with an alternative strategy where unclosed layers are never presented. Instead, only the draw calls up to the first beginLayer() gets rasterized. The content of the layer is preserved for the next frame, where layers can be closed and rasterized as a whole.

Kaiido · 2023-07-24T03:37:39Z

source

+   <li><p>Set all current <span data-x="drawing state">drawing states</span> to the values they have
+   in <var>parentDrawingStates</var>.</p></li>


This should probably exclude the canvas layer state.

This one is tricky to phrase. Let me know what you think.

source

domenic · 2023-08-01T05:46:43Z

source

+  <span>CanvasFilterInput</span>? <dfn data-x="dom-context-2d-beginLayer-options-filter">filter</dfn> = null;
+};
+
+interface mixin <dfn interface>CanvasLayers</dfn> {


Will/should PaintRenderingContext2D also get this mixin?

It should probably. Since it's spec'ed in a different place, I can file a ticket to track this separately. Would that make sense?

source

tuankiet65 · 2023-08-04T01:47:24Z

source

+
+   <li><p>Set all current <span data-x="drawing state">drawing states</span> to the values they have
+   in <var>previousDrawingStates</var>.</p></li>
+  </ol>

  <p>The <dfn method for="CanvasState"><code data-x="dom-context-2d-reset">reset()</code></dfn>
  method steps are to <span>reset the rendering context to its default state</span>.</p>


Resetting a context should also close/discard all currently opened layers right?

Yes. But I think that's already covered in step 3 and 4 below:

"To reset the rendering context to its default state:
....
3 - Clear the context's drawing state stack
4 - Set the context's layer-count to zero."

Isn't it?

But that should be done first. Here canvas's bitmap in step 1 may still be an alias to an open layer, and stating clearly what happens to pending layers may be a good thing too.

I was interpreting "canvas's bitmap" to be the "canvas element's bitmap" (for element canvas), which is different than the "context output bitmap". For instance, in section 4.12.5.1.1, we have:
"The top level output bitmap of a rendering context, when it has one, is always just an alias to a canvas element's bitmap."

But you are right that it whould be made clear that the "context's current output bitmap", which changes when layers are opened, should be restored to point to the canvas element bitmap.

I interpret step 3 and 4 as: literally clear the drawing state stack and not unwinding the stack (like say, if the drawing state stack is a stack variable, just call some clear() method to clear it), and set the layer-count variable to 0 without unwinding opened layers. I think for clarity purposes, it'd be helpful to explicitly specify it like "close all opened layers", or "while layer count is not zero, perform the steps in endLayer()" or even "discard all opened layers".

The thing is, closing all layers is redundant if you are to clear the state stack and reset all states to their default value. In practice, implementations would not close all layers, compositing up all layer outputs and applying filters, just to discard everything in the end. The current spec already uses the step 3 (clear the context's drawing state stack). It's not saying "call restore() in a loop until the state stack is empty.

Maybe I can add a non-normative note saying that these steps have the effect of closing all layers?

There would be an observable difference though: flushing the layers (or calling endLayer) would update the origin-clean flag of the canvas bitmap, while if you don't something like the below snippet would not taint the canvas:

ctx.beginLayer() ctx.drawImage(crossOriginImage, x, y) ctx.reset()

I'm not quite sure what security risks this would involve (since the cross-origin resource would technically never have touched the bitmap), but that would be observable.

(Ps: Testing on the current Canary's implementation the above snippet does taint the canvas, so somehow at least part of the flushing might be done?)

I added a bullet point specifying that the current output bitmap has to be reset to point to the top level output bitmap.

@Kaiido, thanks for pointing out the origin-clean issue. You are correct that closing all layers would give a different result than just resetting the state stack.

The reset() spec should actually say that origin-clean must be set to true. The context does reset the origin-clean flag if the canvas is reset by a size change:

“The flag can be reset in certain situations; for example, when changing the value of the width or the height content attribute of the canvas element to which a CanvasRenderingContext2D is bound, the bitmap is cleared and its origin-clean flag is reset.”
https://html.spec.whatwg.org/multipage/canvas.html#security-with-canvas-elements

Oh, I never noticed that sentence before, but I agree with your reading.
FWIW, this is not interoperable today, only Chrome does reset the flag when changing the canvas size. Can probably be left for another issue.

This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f

This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939633 Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Reviewed-by: Fernando Serboncini <fserb@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212692}

This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. putImageData however is supposed to write to the canvas bitmap wholesale, bypassing all render states. This means that we can't write to the layer's content because the written pixels would then get filtered when the layer is closed. We can't write to the main canvas either because these pixels would later be overwritten by the layer's result with draw calls that potentially happened before (e.g. in the sequence `beginLayer(); fillRect(); putImageData(); endLayer();`, `fillRect()` would write over `putImageData()`. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Change-Id: I266a3155c32919a68dbbb093e4aff9b1dd13a3b5 Bug: 1484741

This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. putImageData however is supposed to write to the canvas bitmap wholesale, bypassing all render states. This means that we can't write to the layer's content because the written pixels would then get filtered when the layer is closed. We can't write to the main canvas either because these pixels would later be overwritten by the layer's result with draw calls that potentially happened before (e.g. in the sequence `beginLayer(); fillRect(); putImageData(); endLayer();`, `fillRect()` would write over `putImageData()`. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Change-Id: I266a3155c32919a68dbbb093e4aff9b1dd13a3b5 Bug: 1484741 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4943172 Reviewed-by: Fernando Serboncini <fserb@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212741}

…map if canvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in transferToImageBitmap if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939633 Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Reviewed-by: Fernando Serboncini <fserb@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212692} -- wpt-commits: 3375400712353d2c9b011ed3dbb24c8d756b784f wpt-pr: 42544

…nvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in putImageData if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. putImageData however is supposed to write to the canvas bitmap wholesale, bypassing all render states. This means that we can't write to the layer's content because the written pixels would then get filtered when the layer is closed. We can't write to the main canvas either because these pixels would later be overwritten by the layer's result with draw calls that potentially happened before (e.g. in the sequence `beginLayer(); fillRect(); putImageData(); endLayer();`, `fillRect()` would write over `putImageData()`. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Change-Id: I266a3155c32919a68dbbb093e4aff9b1dd13a3b5 Bug: 1484741 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4943172 Reviewed-by: Fernando Serboncini <fserb@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212741} -- wpt-commits: 6e6f9fbb0746983001d7fe80ab717567c2f73bfc wpt-pr: 42662

…map if canvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in transferToImageBitmap if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939633 Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Reviewed-by: Fernando Serboncini <fserb@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212692} -- wpt-commits: 3375400712353d2c9b011ed3dbb24c8d756b784f wpt-pr: 42544

…nvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in putImageData if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. putImageData however is supposed to write to the canvas bitmap wholesale, bypassing all render states. This means that we can't write to the layer's content because the written pixels would then get filtered when the layer is closed. We can't write to the main canvas either because these pixels would later be overwritten by the layer's result with draw calls that potentially happened before (e.g. in the sequence `beginLayer(); fillRect(); putImageData(); endLayer();`, `fillRect()` would write over `putImageData()`. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Change-Id: I266a3155c32919a68dbbb093e4aff9b1dd13a3b5 Bug: 1484741 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4943172 Reviewed-by: Fernando Serboncini <fserb@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1212741} -- wpt-commits: 6e6f9fbb0746983001d7fe80ab717567c2f73bfc wpt-pr: 42662

graveljp

I uploaded a commit addressing all review comments. I also made these important changes:

beginLayer now accepts CSS filter strings.
The CanvasRenderingContext2D now has a "top level output bitmap" and a "current output bitmap". The "top level output bitmap" can always be presented to the user, even when layers are open. The content of layers only gets rasterized to the "top level output bitmap" when all layers are closed. This is done by having layers replace and restore the "current output bitmap" to which context draws.

source

graveljp · 2023-08-07T19:11:24Z

source

+  <span>CanvasFilterInput</span>? <dfn data-x="dom-context-2d-beginLayer-options-filter">filter</dfn> = null;
+};
+
+interface mixin <dfn interface>CanvasLayers</dfn> {


It should probably. Since it's spec'ed in a different place, I can file a ticket to track this separately. Would that make sense?

source

graveljp · 2023-11-06T14:33:55Z

source

+  keeping track of the number of opened nested layers. To access the content of the context's
+  <span>output bitmap</span>, the <span>steps for reading the context output bitmap</span> must be
+  used.
+
  <p>The <span>output bitmap</span> has an <span
  data-x="concept-canvas-origin-clean">origin-clean</span> flag, which can be set to true or false.
  Initially, when one of these bitmaps is created, its <span


Layers behave the same as other draw calls for {alpha: false} contexts. The layer content and the layer itself is alpha-blended up to the point where it gets written to the top level output bitmap. I updated the paragraph below to clarify this, and added WPT tests validating this (https://crrev.com/c/5006000).

source

graveljp · 2023-11-07T03:24:29Z

source

+  was flushed by running the steps for <dfn>restoring the drawing state stack</dfn>:</p>
+
+  <ol>
+   <li><p><span data-x="list iterate">For each</span> <var>stateEntry</var> of
+   <var>stateBackup</var>:</p></li>
+
+   <ol>
+    <li><p><span data-x="stack push">Push</span> <var>stateEntry</var> onto the <span>drawing state
+    stack</span>.</p></li>
+   </ol>
+
+   <li><p>Restore the context's current <span>drawing state</span> by running the <code
+   data-x="dom-context-2d-restore">restore()</code> method steps.</p></li>


This section has been removed.

The idea was that when presenting a frame, all the layers would have been closed, the draw calls would have been rasterized, and then, all layers would have been re-opened. This algorithm was describing the logic for re-opening the layers. Only the states were to be re-populated, not the draw calls. On later frame, only new draw calls would get drawn.

This was all replaced with an alternative strategy where unclosed layers are never presented. Instead, only the draw calls up to the first beginLayer() gets rasterized. The content of the layer is preserved for the next frame, where layers can be closed and rasterized as a whole.

source

…map if canvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in transferToImageBitmap if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939633 Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Reviewed-by: Fernando Serboncini <fserbchromium.org> Cr-Commit-Position: refs/heads/main{#1212692} -- wpt-commits: 3375400712353d2c9b011ed3dbb24c8d756b784f wpt-pr: 42544 UltraBlame original commit: 5dcacd6ceadca3d78dab262fdd726b9646edbe7e

…nvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in putImageData if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. putImageData however is supposed to write to the canvas bitmap wholesale, bypassing all render states. This means that we can't write to the layer's content because the written pixels would then get filtered when the layer is closed. We can't write to the main canvas either because these pixels would later be overwritten by the layer's result with draw calls that potentially happened before (e.g. in the sequence `beginLayer(); fillRect(); putImageData(); endLayer();`, `fillRect()` would write over `putImageData()`. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Change-Id: I266a3155c32919a68dbbb093e4aff9b1dd13a3b5 Bug: 1484741 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4943172 Reviewed-by: Fernando Serboncini <fserbchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1212741} -- wpt-commits: 6e6f9fbb0746983001d7fe80ab717567c2f73bfc wpt-pr: 42662 UltraBlame original commit: 685e2ff9c9f305fea2dfd442a95067594d05a6d1

…map if canvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in transferToImageBitmap if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939633 Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Reviewed-by: Fernando Serboncini <fserbchromium.org> Cr-Commit-Position: refs/heads/main{#1212692} -- wpt-commits: 3375400712353d2c9b011ed3dbb24c8d756b784f wpt-pr: 42544 UltraBlame original commit: 5dcacd6ceadca3d78dab262fdd726b9646edbe7e

…nvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in putImageData if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. putImageData however is supposed to write to the canvas bitmap wholesale, bypassing all render states. This means that we can't write to the layer's content because the written pixels would then get filtered when the layer is closed. We can't write to the main canvas either because these pixels would later be overwritten by the layer's result with draw calls that potentially happened before (e.g. in the sequence `beginLayer(); fillRect(); putImageData(); endLayer();`, `fillRect()` would write over `putImageData()`. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Change-Id: I266a3155c32919a68dbbb093e4aff9b1dd13a3b5 Bug: 1484741 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4943172 Reviewed-by: Fernando Serboncini <fserbchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1212741} -- wpt-commits: 6e6f9fbb0746983001d7fe80ab717567c2f73bfc wpt-pr: 42662 UltraBlame original commit: 685e2ff9c9f305fea2dfd442a95067594d05a6d1

…map if canvas layers are opened, a=testonly Automatic update from web-platform-tests Throw an exception in transferToImageBitmap if canvas layers are opened This API is incompatible with how the 2D canvas is rasterized when it contains unclosed layers. Because layers can have filters that get applied on their final content, they can't be presented until they are closed. Instead, we normally keep the layer content alive after a flush, so that it can be presented in a later frame when the layer is finally closed. OffscreenCanvas.transferToImageBitmap however is supposed to release the canvas content, leaving the offscreen canvas empty. We cannot release the recording if layers are incomplete, and if we kept the layer content alive for later, we would not be leaving the canvas empty as the spec requires. This behavior is part of the current 2D Canvas Layer spec draft: Explainer: https://github.com/fserb/canvas2D/blob/master/spec/layers.md Spec draft: whatwg/html#9537 Bug: 1484741 Change-Id: Ic770b51a0343faf0b2c7477624d69f59187ce97f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4939633 Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Reviewed-by: Fernando Serboncini <fserbchromium.org> Cr-Commit-Position: refs/heads/main{#1212692} -- wpt-commits: 3375400712353d2c9b011ed3dbb24c8d756b784f wpt-pr: 42544 UltraBlame original commit: 5dcacd6ceadca3d78dab262fdd726b9646edbe7e

…ons filters tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating BeginLayerOptions filters tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating filters specified via BeginLayerOptions should be marked as tentative. Bug: 40249439 Change-Id: I3d9a009abc04658395b403a8752cf065644fc7f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5903952 Reviewed-by: Andres Ricardo Perez <andresrperez@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1364414} -- wpt-commits: 13948ad5eb4121e95d7137e54d666eafe413e72f wpt-pr: 48477

…tions tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating layers with options tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating BeginLayerOptions should be marked as tentative. To prevent losing test coverage, this CL adds test variants using context filters in addition to layer filters. Bug: 40249439 Change-Id: Ic06dfa911969075bee42a20f0518beab2bc98fa7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5904350 Reviewed-by: Andres Ricardo Perez <andresrperez@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1365604} -- wpt-commits: bf7c101faf285e73a2e35a8a4ae26e3d805b9548 wpt-pr: 48522

…ons filters tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating BeginLayerOptions filters tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating filters specified via BeginLayerOptions should be marked as tentative. Bug: 40249439 Change-Id: I3d9a009abc04658395b403a8752cf065644fc7f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5903952 Reviewed-by: Andres Ricardo Perez <andresrperez@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1364414} -- wpt-commits: 13948ad5eb4121e95d7137e54d666eafe413e72f wpt-pr: 48477

…tions tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating layers with options tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating BeginLayerOptions should be marked as tentative. To prevent losing test coverage, this CL adds test variants using context filters in addition to layer filters. Bug: 40249439 Change-Id: Ic06dfa911969075bee42a20f0518beab2bc98fa7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5904350 Reviewed-by: Andres Ricardo Perez <andresrperez@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1365604} -- wpt-commits: bf7c101faf285e73a2e35a8a4ae26e3d805b9548 wpt-pr: 48522

…ons filters tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating BeginLayerOptions filters tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating filters specified via BeginLayerOptions should be marked as tentative. Bug: 40249439 Change-Id: I3d9a009abc04658395b403a8752cf065644fc7f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5903952 Reviewed-by: Andres Ricardo Perez <andresrperezchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1364414} -- wpt-commits: 13948ad5eb4121e95d7137e54d666eafe413e72f wpt-pr: 48477 UltraBlame original commit: b6e8051aa3fb22c636d6ae835976f2b791569b08

…tions tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating layers with options tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating BeginLayerOptions should be marked as tentative. To prevent losing test coverage, this CL adds test variants using context filters in addition to layer filters. Bug: 40249439 Change-Id: Ic06dfa911969075bee42a20f0518beab2bc98fa7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5904350 Reviewed-by: Andres Ricardo Perez <andresrperezchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1365604} -- wpt-commits: bf7c101faf285e73a2e35a8a4ae26e3d805b9548 wpt-pr: 48522 UltraBlame original commit: 5d5bbdf6ce6d994eb36ab954ece44a5c3aa0d3e4

…ons filters tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating BeginLayerOptions filters tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating filters specified via BeginLayerOptions should be marked as tentative. Bug: 40249439 Change-Id: I3d9a009abc04658395b403a8752cf065644fc7f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5903952 Reviewed-by: Andres Ricardo Perez <andresrperezchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1364414} -- wpt-commits: 13948ad5eb4121e95d7137e54d666eafe413e72f wpt-pr: 48477 UltraBlame original commit: b6e8051aa3fb22c636d6ae835976f2b791569b08

…tions tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating layers with options tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating BeginLayerOptions should be marked as tentative. To prevent losing test coverage, this CL adds test variants using context filters in addition to layer filters. Bug: 40249439 Change-Id: Ic06dfa911969075bee42a20f0518beab2bc98fa7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5904350 Reviewed-by: Andres Ricardo Perez <andresrperezchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1365604} -- wpt-commits: bf7c101faf285e73a2e35a8a4ae26e3d805b9548 wpt-pr: 48522 UltraBlame original commit: 5d5bbdf6ce6d994eb36ab954ece44a5c3aa0d3e4

…ons filters tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating BeginLayerOptions filters tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating filters specified via BeginLayerOptions should be marked as tentative. Bug: 40249439 Change-Id: I3d9a009abc04658395b403a8752cf065644fc7f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5903952 Reviewed-by: Andres Ricardo Perez <andresrperezchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1364414} -- wpt-commits: 13948ad5eb4121e95d7137e54d666eafe413e72f wpt-pr: 48477 UltraBlame original commit: b6e8051aa3fb22c636d6ae835976f2b791569b08

…tions tentative, a=testonly Automatic update from web-platform-tests Make WPT tests validating layers with options tentative The beginLayer's BeginLayerOption parameter was removed from the canvas layer PR at whatwg/html#9537. We might pursue this as a followup. In the meantime, the tests validating BeginLayerOptions should be marked as tentative. To prevent losing test coverage, this CL adds test variants using context filters in addition to layer filters. Bug: 40249439 Change-Id: Ic06dfa911969075bee42a20f0518beab2bc98fa7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5904350 Reviewed-by: Andres Ricardo Perez <andresrperezchromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravelchromium.org> Cr-Commit-Position: refs/heads/main{#1365604} -- wpt-commits: bf7c101faf285e73a2e35a8a4ae26e3d805b9548 wpt-pr: 48522 UltraBlame original commit: 5d5bbdf6ce6d994eb36ab954ece44a5c3aa0d3e4

annevk · 2024-11-12T10:14:26Z

This needs rebasing, but it's also not entirely clear to me this has support from WebKit. After double checking colleagues we see value in the CSS-based mechanism to specify filters, but not the XML-derived object model. We also gave this feedback last year in the corresponding issue.

graveljp · 2024-11-12T14:54:10Z

we see value in the CSS-based mechanism to specify filters, but not the XML-derived object model

This has been addressed already. The XML filter support was dropped in #9537 (comment), in favor of supporting only CSS filters. After receiving more feedback from WebKit, I then dropped the layer's filter parameter altogether, in favor of using the context filter. See #9537 (comment).

annevk · 2024-11-12T15:56:34Z

My apologies, I was led to believe that feedback was still unaddressed. If you are willing to resolve the branch conflicts I can take care of review by Nov 22 (aiming for early next week). Hopefully @Kaiido can also make some time as they often have useful insights.

This adds new beginLayer and endLayer functions to open and close layers in the canvas. While layers are active, draw calls operate on a separate texture that gets composited to the parent output bitmap when the layer is closed. An optional filter can be specified in beginLayer, allowing effects to be applied to the layer's texture when it's composited its parent. Tests: https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/layers https://github.com/web-platform-tests/wpt/tree/master/html/canvas/offscreen/layers Fixes whatwg#8476

This update addresses 3 main things: - Support for CSS filter strings was added to the beginLayer API - Unclosed layers are now never rasterized when the canvas is presented to the user. Instead, the content of the layer is preserved and will be rasterized in a later frame, if/when the layer is closed. - Replied to the first round of review comments.

This will be moved to a separate pull request.

With this change, the context filters now applies to the layer's output bitmap and is resetted to "none" when entering layers.

This removes the filter argument of the beginLayer API. BeginLayerOptions can possibliy be added to the specification as a follow-up.

The HTMLCanvasElement's bitmap was linkified to clarify to which bitmap each uses of the word "bitmap" refers to (either the element's bitmap, the context's top level output bitmap or the context's current output bitmap).

This means that when entering a layer, the current transform now is reset to the identity matrix. setTransform and getTransform are now local to the current layer, meaning that calling setTransform sets a matrix relative to the parent layer.

With how the spec is written now, the context always has a top level and a current output bitmap, irrespective of how the context's bitmap is bound or used by an HTMLCanvasElement or OffscreenCanvas. Thus, the paragraph modified by this commit wasn't correct. It's more useful to describe how the state stack as a whole relates with the context's state.

Most uses were plural already. Making them all plural is more consistent and allows to remove the data-x that was needed to reconcile the differences.

graveljp · 2024-11-15T00:27:38Z

I rebased the PR and added a few minor fixes.

annevk · 2024-11-15T10:59:13Z

source

-  <code>canvas</code>'s bitmap. This content may be placed as content of the <code>canvas</code>
-  element. The contents of the <code>canvas</code> element, if any, are the element's <span>fallback
-  content</span>.</p>
+  <span data-x="canvas-bitmap"><code>canvas</code>'s bitmap</span>. This content may be placed as


I would only use  around bitmap here. It's a concept that belongs to the canvas element after all. This applies elsewhere too.

I'm not sure I follow. Do you mean that I should write: <code>canvas</code>'s bitmap ? I added this ID to differentiate the different types of bitmaps. For instance, the data-x "canvas-bitmap" is a different concept than "offscreencanvas-bitmap". I needed this to clarify how
the top level output bitmap is an alias for the canvas element's bitmap, and that the offscreencanvas-bitmap is the analogue to the canvas-bitmap. Wouldn't it be confusing to have different bitmap refer to different concepts?

Do you mean that I should write: <code>canvas</code>'s bitmap?

Yes.

Wouldn't it be confusing to have different bitmap refer to different concepts?

Not if the context makes it clear which it is. (And since it's something that belongs to something else, there's always going to be context.) This is an established pattern.

source

annevk · 2024-11-15T11:07:52Z

source

-  <p>Objects that implement the <code>CanvasState</code> interface maintain a stack of drawing
-  states. <dfn data-x="drawing state">Drawing states</dfn> consist of:</p>
+  <p>Objects that implement the <code>CanvasState</code> interface maintain a <dfn data-x="drawing
+  states stack">stack of drawing states</dfn>. <dfn>Drawing states</dfn> consist of:</p>


By removing data-x you have changed the ID as well. I guess removing data-x is okay, but then you need to explicitly state the ID so it does not get changed.

What do you mean by removing data-x while explicitly stating the ID? Isn't the ID specified with a data-x?

For context, I was changing the ID to make it plural because most uses of drawing states was plural already and the singular uses felt inconsistent. I could not consider drawing state as a structure (which would have had a singular name) because it was defined as a list of current context states. drawing states was conflating current context states and states we save in the state stack. Thus, I opted for the plural form, not as a structure name but more like a list of related concepts invoked in different places of the spec.

I now updated this section to try to alleviate the confusion. I separated the concept of a drawing state struct that we save in the state stack from the set of current states the context operates on. Drawing state now contains "A clipping region", as opposed to "The current clipping region". The context now has a current drawing state (which indirectly implies it has a current clipping region). I think that this is much cleaner. But it caused trouble with the current transformation matrix. If the drawing state contains a current transformation matrix, then the context would be using a current current transformation matrix. To address this, I renamed this matrix to layer transformation matrix, that is, it's the transformation matrix active in a layer. I originally wanted to name it like that but didn't only because I was trying to minimize the scope of the change (renaming the current transformation matrix might have ripple effects, like having to update the MDN documentation to refer to the current layer's transformation matrix for instance).

What do you think of these changes?

No, data-x specifies the cross-reference term. The ID is derived from that, but can also be set independently through the id attribute.

These changes sound good. In general the 2D canvas section has been much too hand-wavy. And in general I wouldn't worry too much about implications for everything that is downstream from the specification, except for incoming links. The most important thing is that we describe the model well, as everything else flows from that.

source

annevk · 2024-11-15T11:17:35Z

source

+   <li><p>Draw <var>layerOutputBitmap</var> onto <span>this</span>'s <span>current output
+   bitmap</span> using the steps outlined in the <span>drawing model</span>.</p></li>
+
+   <li><p>Decrement <span>this</span>'s <span data-x="concept-canvas-layer-count">layer count</span>


Shouldn't this be concept-context-2d-layer-count here and elsewhere?

I don't mind changing this, but note that I used concept-canvas because lots of other nearby dfns use that prefix: concept-canvas-origin-clean, concept-canvas-global-alpha, concept-canvas-context-mode, etc. On the other hand, not a single dfn uses concept-context-2d prefix anywhere in the spec.

Thoughts?

I guess we can continue to use canvas then, but it seems a bit confusing that it houses both canvas element and 2d context concepts.

annevk · 2024-11-15T11:18:37Z

source

-  <p>The <code>canvas</code> element provides scripts with a resolution-dependent bitmap canvas,
-  which can be used for rendering graphs, game graphics, art, or other visual images on the fly.</p>
+  <p>The <code>canvas</code> element provides scripts with a resolution-dependent <dfn
+  data-x="canvas-bitmap">bitmap canvas</dfn>, which can be used for rendering graphs, game graphics,


How does this work for OffscreenCanvas?

The OffscreenCanvas is defined as having its own bitmap (data-x="offscreencanvas-bitmap"). OffscreenCanvasRenderingContext2D is then defined as a context similar to CanvasRenderingContext2D, but drawing to that offscreencanvas-bitmap. Below, this PR adds this clarification:

This bitmap plays the same role as <code>CanvasRenderingContext2D</code>'s top level output bitmap

Main changes include clarifications in the `drawing state` definition and renaming `current transformation matrix` to `layer transformation matrix`.

graveljp

Thanks!

graveljp · 2024-11-18T22:13:57Z

source

-  <p>The <code>canvas</code> element provides scripts with a resolution-dependent bitmap canvas,
-  which can be used for rendering graphs, game graphics, art, or other visual images on the fly.</p>
+  <p>The <code>canvas</code> element provides scripts with a resolution-dependent <dfn
+  data-x="canvas-bitmap">bitmap canvas</dfn>, which can be used for rendering graphs, game graphics,


The OffscreenCanvas is defined as having its own bitmap (data-x="offscreencanvas-bitmap"). OffscreenCanvasRenderingContext2D is then defined as a context similar to CanvasRenderingContext2D, but drawing to that offscreencanvas-bitmap. Below, this PR adds this clarification:

This bitmap plays the same role as <code>CanvasRenderingContext2D</code>'s top level output bitmap

graveljp · 2024-11-19T01:45:50Z

source

-  <code>canvas</code>'s bitmap. This content may be placed as content of the <code>canvas</code>
-  element. The contents of the <code>canvas</code> element, if any, are the element's <span>fallback
-  content</span>.</p>
+  <span data-x="canvas-bitmap"><code>canvas</code>'s bitmap</span>. This content may be placed as


I'm not sure I follow. Do you mean that I should write: <code>canvas</code>'s bitmap ? I added this ID to differentiate the different types of bitmaps. For instance, the data-x "canvas-bitmap" is a different concept than "offscreencanvas-bitmap". I needed this to clarify how
the top level output bitmap is an alias for the canvas element's bitmap, and that the offscreencanvas-bitmap is the analogue to the canvas-bitmap. Wouldn't it be confusing to have different bitmap refer to different concepts?

graveljp · 2024-11-19T16:45:38Z

source

-  <p>Objects that implement the <code>CanvasState</code> interface maintain a stack of drawing
-  states. <dfn data-x="drawing state">Drawing states</dfn> consist of:</p>
+  <p>Objects that implement the <code>CanvasState</code> interface maintain a <dfn data-x="drawing
+  states stack">stack of drawing states</dfn>. <dfn>Drawing states</dfn> consist of:</p>


What do you mean by removing data-x while explicitly stating the ID? Isn't the ID specified with a data-x?

For context, I was changing the ID to make it plural because most uses of drawing states was plural already and the singular uses felt inconsistent. I could not consider drawing state as a structure (which would have had a singular name) because it was defined as a list of current context states. drawing states was conflating current context states and states we save in the state stack. Thus, I opted for the plural form, not as a structure name but more like a list of related concepts invoked in different places of the spec.

I now updated this section to try to alleviate the confusion. I separated the concept of a drawing state struct that we save in the state stack from the set of current states the context operates on. Drawing state now contains "A clipping region", as opposed to "The current clipping region". The context now has a current drawing state (which indirectly implies it has a current clipping region). I think that this is much cleaner. But it caused trouble with the current transformation matrix. If the drawing state contains a current transformation matrix, then the context would be using a current current transformation matrix. To address this, I renamed this matrix to layer transformation matrix, that is, it's the transformation matrix active in a layer. I originally wanted to name it like that but didn't only because I was trying to minimize the scope of the change (renaming the current transformation matrix might have ripple effects, like having to update the MDN documentation to refer to the current layer's transformation matrix for instance).

What do you think of these changes?

source

graveljp · 2024-11-19T20:30:37Z

source

+   <li><p>Draw <var>layerOutputBitmap</var> onto <span>this</span>'s <span>current output
+   bitmap</span> using the steps outlined in the <span>drawing model</span>.</p></li>
+
+   <li><p>Decrement <span>this</span>'s <span data-x="concept-canvas-layer-count">layer count</span>


I don't mind changing this, but note that I used concept-canvas because lots of other nearby dfns use that prefix: concept-canvas-origin-clean, concept-canvas-global-alpha, concept-canvas-context-mode, etc. On the other hand, not a single dfn uses concept-context-2d prefix anywhere in the spec.

Thoughts?

source

graveljp mentioned this pull request Jul 19, 2023

Canvas2D layers with filter support #8476

Open

fserb requested a review from domenic July 20, 2023 18:09

Kaiido suggested changes Jul 24, 2023

View reviewed changes

domenic requested changes Aug 1, 2023

View reviewed changes

tuankiet65 reviewed Aug 4, 2023

View reviewed changes

chromium-wpt-export-bot mentioned this pull request Oct 13, 2023

Throw an exception in transferToImageBitmap if canvas layers are opened web-platform-tests/wpt#42544

Merged

chromium-wpt-export-bot mentioned this pull request Oct 20, 2023

Throw an exception in putImageData if canvas layers are opened web-platform-tests/wpt#42662

Merged

foolip mentioned this pull request Oct 25, 2023

Canvas2D filter and reset web-platform-tests/interop#493

Closed

3 tasks

graveljp commented Nov 7, 2023

View reviewed changes

graveljp force-pushed the layer-filter-spec branch from e08cdf8 to 0868d09 Compare November 7, 2023 17:54

graveljp and others added 12 commits November 14, 2024 18:06

Fix <ref> syntax

9d4d816

Fixed editorial issues

5caa39a

Remove XML CanvasFilter from initial layer spec

7a74000

This will be moved to a separate pull request.

Add ctx.filter to the layer rendering states

9dafd05

With this change, the context filters now applies to the layer's output bitmap and is resetted to "none" when entering layers.

Remove BeginLayerOptions

809c650

This removes the filter argument of the beginLayer API. BeginLayerOptions can possibliy be added to the specification as a follow-up.

Clarify what type of bitmaps are used across the canvas spec

1630ffa

The HTMLCanvasElement's bitmap was linkified to clarify to which bitmap each uses of the word "bitmap" refers to (either the element's bitmap, the context's top level output bitmap or the context's current output bitmap).

Remove dfn that should have been deleted along with the XML filter spec

3f3cc52

Make all instances of "drawing states" plural

1db7673

Most uses were plural already. Making them all plural is more consistent and allows to remove the data-x that was needed to reconcile the differences.

graveljp force-pushed the layer-filter-spec branch from 1fc4c42 to 8a626cf Compare November 14, 2024 23:35

annevk reviewed Nov 15, 2024

View reviewed changes

Reply to review comment

3378c5d

Main changes include clarifications in the `drawing state` definition and renaming `current transformation matrix` to `layer transformation matrix`.

graveljp commented Nov 20, 2024

View reviewed changes


		<div w-nodev>

		<p>Before any operations could access the <code>canvas</code> element's bitmap pixels, the

		<li><p>Set all current <span data-x="drawing state">drawing states</span> to the values they have
		in <var>parentDrawingStates</var>.</p></li>

Add a layer and filter interface in the 2D canvas #9537

Are you sure you want to change the base?

Add a layer and filter interface in the 2D canvas #9537

Conversation

graveljp commented Jul 19, 2023 • edited by pr-preview bot Loading

Kaiido left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

graveljp Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tuankiet65 Aug 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kaiido Aug 5, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

graveljp left a comment

Choose a reason for hiding this comment

graveljp Aug 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Nov 12, 2024

graveljp commented Nov 12, 2024

annevk commented Nov 12, 2024

graveljp commented Nov 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

graveljp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

graveljp commented Jul 19, 2023 •

edited by pr-preview bot

Loading

graveljp Aug 7, 2023 •

edited

Loading

tuankiet65 Aug 4, 2023 •

edited

Loading

Kaiido Aug 5, 2023 •

edited

Loading

graveljp Aug 7, 2023 •

edited

Loading