[skwasm] Port to `DisplayList` objects #172314

eyebrowsoffire · 2025-07-17T20:38:00Z

This PR refactors the skwasm renderer to use DisplayList objects as its main model objects instead of using Skia objects directly. Then, at render time, we dispatch the display list commands to the skia surface. This is a preparatory step for impeller on web.

Some build rules were reworked in order to allow DisplayList to compile via emscripten
Some pieces of the display list library were further refactored to allow us to compile it without actually building and linking the impeller shaders. The two major classes that needed to be separated out were DlRuntimeEffect and the text drawing system.
SkPath and SkImage are still used as the main model objects in skwasm. As of right now, DisplayList just thinly wraps these objects, so this is the minimal possible change for now. I will have to refactor this somewhat further when preparing for actual impeller adoption.
Several special cased code paths in skwasm were removed, as they are taken care of by DisplayList itself. This includes shadow drawing, determining when to enable dithering, and determining the right clamp value for filters.

harryterkelsen

The web_ui parts LGTM. I don't know enough about the native engine to comment on the display_list changes except to note that some of them seem orthogonal to the web_ui changes. I think the drawText and runtime effects changes could be a separate PR.

eyebrowsoffire · 2025-08-20T21:37:50Z

The web_ui parts LGTM. I don't know enough about the native engine to comment on the display_list changes except to note that some of them seem orthogonal to the web_ui changes. I think the drawText and runtime effects changes could be a separate PR.

The drawText and runtime effect changes are there to decouple some impeller things from the main display list library. If I didn't do them in this change, depending on the display_list library would pull in a bunch of impeller stuff that doesn't yet compile on emscripten. I'd have to do a bunch more massaging to get that code working on the web build, and I'd rather do that in a subsequent PR when I'm actually adding the impeller backend.

flar · 2025-08-20T21:40:47Z

The web_ui parts LGTM. I don't know enough about the native engine to comment on the display_list changes except to note that some of them seem orthogonal to the web_ui changes. I think the drawText and runtime effects changes could be a separate PR.

The drawText and runtime effect changes are there to decouple some impeller things from the main display list library. If I didn't do them in this change, depending on the display_list library would pull in a bunch of impeller stuff that doesn't yet compile on emscripten. I'd have to do a bunch more massaging to get that code working on the web build, and I'd rather do that in a subsequent PR when I'm actually adding the impeller backend.

I thought the same thing, but you are looking at it backwards. If you land DlText first then it works, but you'd have to hold off on the skwasm changes until that PR lands. Your call, but they can be separated...

eyebrowsoffire · 2025-08-20T21:51:28Z

The web_ui parts LGTM. I don't know enough about the native engine to comment on the display_list changes except to note that some of them seem orthogonal to the web_ui changes. I think the drawText and runtime effects changes could be a separate PR.

The drawText and runtime effect changes are there to decouple some impeller things from the main display list library. If I didn't do them in this change, depending on the display_list library would pull in a bunch of impeller stuff that doesn't yet compile on emscripten. I'd have to do a bunch more massaging to get that code working on the web build, and I'd rather do that in a subsequent PR when I'm actually adding the impeller backend.

I thought the same thing, but you are looking at it backwards. If you land DlText first then it works, but you'd have to hold off on the skwasm changes until that PR lands. Your call, but they can be separated...

Actually yes, you're right. If you think it's important, I can try to split this PR out.

flar · 2025-08-20T22:03:49Z

The web_ui parts LGTM. I don't know enough about the native engine to comment on the display_list changes except to note that some of them seem orthogonal to the web_ui changes. I think the drawText and runtime effects changes could be a separate PR.

The drawText and runtime effect changes are there to decouple some impeller things from the main display list library. If I didn't do them in this change, depending on the display_list library would pull in a bunch of impeller stuff that doesn't yet compile on emscripten. I'd have to do a bunch more massaging to get that code working on the web build, and I'd rather do that in a subsequent PR when I'm actually adding the impeller backend.

I thought the same thing, but you are looking at it backwards. If you land DlText first then it works, but you'd have to hold off on the skwasm changes until that PR lands. Your call, but they can be separated...

Actually yes, you're right. If you think it's important, I can try to split this PR out.

I think it was a missed opportunity, but given the logistics of having them baked independently when they are both ready to go right now is so constrained that there isn't much point of doing it at this stage.

harryterkelsen · 2025-08-20T22:09:29Z

The web_ui parts LGTM. I don't know enough about the native engine to comment on the display_list changes except to note that some of them seem orthogonal to the web_ui changes. I think the drawText and runtime effects changes could be a separate PR.

The drawText and runtime effect changes are there to decouple some impeller things from the main display list library. If I didn't do them in this change, depending on the display_list library would pull in a bunch of impeller stuff that doesn't yet compile on emscripten. I'd have to do a bunch more massaging to get that code working on the web build, and I'd rather do that in a subsequent PR when I'm actually adding the impeller backend.

I thought the same thing, but you are looking at it backwards. If you land DlText first then it works, but you'd have to hold off on the skwasm changes until that PR lands. Your call, but they can be separated...

Actually yes, you're right. If you think it's important, I can try to split this PR out.

I think it was a missed opportunity, but given the logistics of having them baked independently when they are both ready to go right now is so constrained that there isn't much point of doing it at this stage.

Agreed

flar

I think I reviewed all of the DL code here. Lots of suggestions.

flar · 2025-08-20T22:08:19Z

engine/src/flutter/impeller/display_list/dl_dispatcher.h

  void transformReset() override;

-  void drawTextFrame(const std::shared_ptr<impeller::TextFrame>& text_frame,
+  void drawText(const std::shared_ptr<flutter::DlText>& text,


Didn't the following lines fail the format check?

Oh, we turn off formatting for the transform methods (which have a strong preference for how the arguments line up) at line 340-ish and never turn it back on... D'oh!

Maybe just fix the formatting on these 3 lines and leave the "uh oh, we need to turn formatting back on" for a separate PR.

I went ahead and fixed the formatting in this file (in the other PR).

flar · 2025-08-20T22:13:23Z

engine/src/flutter/display_list/dl_text.h

+// found in the LICENSE file.
+
+#ifndef FLUTTER_DISPLAY_LIST_DL_TEXT_H_
+#define FLUTTER_DISPLAY_LIST_DL_TEXT_H_


We've been making .cc files for every .h file even if they have no code in them even if just to verify that they can compile without any issues.

See dl_types.h/cc for example.

Also, your call as to whether to move the impl into the .cc file. I think it is a decent gesture unless templating requires all of the code to go into the .h file. Though, if it is just getters then it feels like an empty gesture. But we still create the empty .cc file...

flar · 2025-08-20T22:15:44Z

engine/src/flutter/display_list/dl_text_skia.h

+// found in the LICENSE file.
+
+#ifndef FLUTTER_DISPLAY_LIST_DL_TEXT_SKIA_H_
+#define FLUTTER_DISPLAY_LIST_DL_TEXT_SKIA_H_


Also, a .cc file...

flar · 2025-08-20T22:21:40Z

engine/src/flutter/display_list/dl_builder.h

-                    DlScalar y,
-                    const DlPaint& paint) override;
-
-  void drawTextFrame(const std::shared_ptr<impeller::TextFrame>& text_frame,


Does a double take...

Oops, this was supposed to be in the private section anyway. D'oh!

flar · 2025-08-20T22:22:58Z

engine/src/flutter/display_list/dl_canvas.h


-#include "impeller/typographer/text_frame.h"
+namespace impeller {
+class TextFrame;


Do we really need this in the .h file?

And do we still need to include SkTextBlob either?

flar · 2025-08-20T22:57:22Z

engine/src/flutter/display_list/display_list_unittests.cc

                            DlBlendMode::kSrcOver, DlImageSampling::kLinear,
                            nullptr, &paint);
-          builder.DrawTextBlob(GetTestTextBlob(1), 10, 10, paint);
+          builder.DrawText(DlTextSkia::Make(GetTestTextBlob(1)), 10, 10, paint);


Ditto, DlTextImpeller case if it is easy to make the appropriate test frame.

flar · 2025-08-20T22:59:55Z

engine/src/flutter/display_list/dl_builder.cc

-                                      DlScalar y,
-                                      const DlPaint& paint) {
+
+void DisplayListBuilder::DrawText(const std::shared_ptr<DlText>& text,


Minor nit. All of the pairs in this file are "internal op method first, then public canvas method". In the surgery here you've flipped that ordering. (OCD triggering)

flar · 2025-08-20T23:00:47Z

engine/src/flutter/display_list/dl_builder.cc

-    DlScalar x,
-    DlScalar y,
-    const DlPaint& paint) {
-  SetAttributesFromPaint(paint, DisplayListOpFlags::kDrawTextBlobFlags);


Rename kDrawTextBlobFlags now maybe?

flar · 2025-08-20T23:03:35Z

engine/src/flutter/display_list/testing/dl_test_snippets.cc

+           {1, 32, 1,
            [](DlOpReceiver& r) {
-              r.drawTextBlob(GetTestTextBlob(2), 10, 10);
+              r.drawText(DlTextSkia::Make(GetTestTextBlob(2)), 10, 10);


Maybe add a (set of) DlTextImpeller case(s). Should it/they be != to all TextSkia cases?

flar · 2025-08-20T23:04:31Z

engine/src/flutter/flow/layers/performance_overlay_layer.cc

-      canvas->DrawTextFrame(impeller::MakeTextFrameFromTextBlobSkia(text),
-                            x + label_x, y + height + label_y, paint);
+      canvas->DrawText(
+          DlTextImpeller::Make(impeller::MakeTextFrameFromTextBlobSkia(text)),


Is there any logistical value for a suggestion to have DlTextImpeller have a "MakeBlob" factory to do the conversion for the caller?

eyebrowsoffire · 2025-08-21T15:40:40Z

Since this is a big PR, and there's a nonzero chance we'll need to revert if something goes wrong, I think it actually is worthwhile to separate the display list stuff out, so I did so in this PR: #174219

I'll address Jim's comments over in that one, and then once we have that one landed I'll rebase this PR and the diffs should be smaller.

flar · 2025-08-21T20:58:05Z

Since this is a big PR, and there's a nonzero chance we'll need to revert if something goes wrong, I think it actually is worthwhile to separate the display list stuff out, so I did so in this PR: #174219

I'll address Jim's comments over in that one, and then once we have that one landed I'll rebase this PR and the diffs should be smaller.

Well the DlText part was 77 of these 104 files which hopefully means the skwasm changes will be much simpler...

…entations. (#174219) This makes two refactors to the display list architecture: * The concrete implementations of `DlRuntimeEffect` for skia and impeller are separated, and the impeller implementation put into the `impeller/display_list` target. This makes sure that a client can link against the main `display_list` library without actually pulling in all of impeller. (This is needed for #172314) * The `DrawTextBlob` and `DrawTextFrame` methods are consolidated into one `DrawText` call, and that takes a `DlText` object. The `DlText` object has two implementations, one for skia and one for impeller, and the impeller one is moved into `impeller/display_list` for the same reason mentioned above.

This PR refactors the skwasm renderer to use DisplayList objects as its main model objects instead of using Skia objects directly. Then, at render time, we dispatch the display list commands to the skia surface. This is a preparatory step for impeller on web. * Some build rules were reworked in order to allow DisplayList to compile via emscripten * SkPath and SkImage are still used as the main model objects in skwasm. As of right now, DisplayList just thinly wraps these objects, so this is the minimal possible change for now. I will have to refactor this somewhat further when preparing for actual impeller adoption. * Several special cased code paths in skwasm were removed, as they are taken care of by DisplayList itself. This includes shadow drawing, determining when to enable dithering, and determining the right clamp value for filters.

eyebrowsoffire · 2025-08-22T21:11:28Z

I landed the non-skwasm related changes which do some refactors to DisplayList here: #174219

And I reconfigured this PR to only have the skwasm changes in it now.

flar

Deferring to @harryterkelsen now...

flar

Can't "unrequest changes" - must approve.

For the record, I didn't really review any of the code that's left, assuming that @harryterkelsen took care of that...

)

flutter/flutter@edd434a...a4cb00a 2025-08-25 [email protected] Clarify how Gemini should handle conflicting guidelines (flutter/flutter#174294) 2025-08-25 [email protected] [skwasm] Port to `DisplayList` objects (flutter/flutter#172314) 2025-08-25 [email protected] Roll Packages from 092d832 to fe66130 (4 revisions) (flutter/flutter#174373) 2025-08-25 [email protected] Roll Dart SDK from 4f9623f024ab to e283a9e88242 (8 revisions) (flutter/flutter#174358) 2025-08-25 [email protected] Roll Skia from 3bcd0a1d8c48 to da724d312e65 (1 revision) (flutter/flutter#174357) 2025-08-25 [email protected] Roll Skia from 8689a1169a32 to 3bcd0a1d8c48 (4 revisions) (flutter/flutter#174353) 2025-08-25 [email protected] Roll Fuchsia Linux SDK from 21v1vYTYWmyEHu-eP... to UiY8gj468PZUj6QTm... (flutter/flutter#174349) 2025-08-24 [email protected] Roll Skia from 61169c1f6f7c to 8689a1169a32 (2 revisions) (flutter/flutter#174343) 2025-08-24 [email protected] Roll Fuchsia Linux SDK from XLSNQCsY1VkIthSjt... to 21v1vYTYWmyEHu-eP... (flutter/flutter#174332) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-packages Please CC [email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Packages: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

engine/src/flutter/lib/web_ui/lib/src/engine/skwasm/skwasm_impl/paint.dart

…entations. (flutter#174219) This makes two refactors to the display list architecture: * The concrete implementations of `DlRuntimeEffect` for skia and impeller are separated, and the impeller implementation put into the `impeller/display_list` target. This makes sure that a client can link against the main `display_list` library without actually pulling in all of impeller. (This is needed for flutter#172314) * The `DrawTextBlob` and `DrawTextFrame` methods are consolidated into one `DrawText` call, and that takes a `DlText` object. The `DlText` object has two implementations, one for skia and one for impeller, and the impeller one is moved into `impeller/display_list` for the same reason mentioned above.

This PR refactors the skwasm renderer to use `DisplayList` objects as its main model objects instead of using Skia objects directly. Then, at render time, we dispatch the display list commands to the skia surface. This is a preparatory step for impeller on web. * Some build rules were reworked in order to allow `DisplayList` to compile via emscripten * Some pieces of the display list library were further refactored to allow us to compile it without actually building and linking the impeller shaders. The two major classes that needed to be separated out were `DlRuntimeEffect` and the text drawing system. * `SkPath` and `SkImage` are still used as the main model objects in skwasm. As of right now, `DisplayList` just thinly wraps these objects, so this is the minimal possible change for now. I will have to refactor this somewhat further when preparing for actual impeller adoption. * Several special cased code paths in skwasm were removed, as they are taken care of by `DisplayList` itself. This includes shadow drawing, determining when to enable dithering, and determining the right clamp value for filters.

…entations. (flutter#174219) This makes two refactors to the display list architecture: * The concrete implementations of `DlRuntimeEffect` for skia and impeller are separated, and the impeller implementation put into the `impeller/display_list` target. This makes sure that a client can link against the main `display_list` library without actually pulling in all of impeller. (This is needed for flutter#172314) * The `DrawTextBlob` and `DrawTextFrame` methods are consolidated into one `DrawText` call, and that takes a `DlText` object. The `DlText` object has two implementations, one for skia and one for impeller, and the impeller one is moved into `impeller/display_list` for the same reason mentioned above.

This PR refactors the skwasm renderer to use `DisplayList` objects as its main model objects instead of using Skia objects directly. Then, at render time, we dispatch the display list commands to the skia surface. This is a preparatory step for impeller on web. * Some build rules were reworked in order to allow `DisplayList` to compile via emscripten * Some pieces of the display list library were further refactored to allow us to compile it without actually building and linking the impeller shaders. The two major classes that needed to be separated out were `DlRuntimeEffect` and the text drawing system. * `SkPath` and `SkImage` are still used as the main model objects in skwasm. As of right now, `DisplayList` just thinly wraps these objects, so this is the minimal possible change for now. I will have to refactor this somewhat further when preparing for actual impeller adoption. * Several special cased code paths in skwasm were removed, as they are taken care of by `DisplayList` itself. This includes shadow drawing, determining when to enable dithering, and determining the right clamp value for filters.

…entations. (flutter#174219) This makes two refactors to the display list architecture: * The concrete implementations of `DlRuntimeEffect` for skia and impeller are separated, and the impeller implementation put into the `impeller/display_list` target. This makes sure that a client can link against the main `display_list` library without actually pulling in all of impeller. (This is needed for flutter#172314) * The `DrawTextBlob` and `DrawTextFrame` methods are consolidated into one `DrawText` call, and that takes a `DlText` object. The `DlText` object has two implementations, one for skia and one for impeller, and the impeller one is moved into `impeller/display_list` for the same reason mentioned above.

This PR refactors the skwasm renderer to use `DisplayList` objects as its main model objects instead of using Skia objects directly. Then, at render time, we dispatch the display list commands to the skia surface. This is a preparatory step for impeller on web. * Some build rules were reworked in order to allow `DisplayList` to compile via emscripten * Some pieces of the display list library were further refactored to allow us to compile it without actually building and linking the impeller shaders. The two major classes that needed to be separated out were `DlRuntimeEffect` and the text drawing system. * `SkPath` and `SkImage` are still used as the main model objects in skwasm. As of right now, `DisplayList` just thinly wraps these objects, so this is the minimal possible change for now. I will have to refactor this somewhat further when preparing for actual impeller adoption. * Several special cased code paths in skwasm were removed, as they are taken care of by `DisplayList` itself. This includes shadow drawing, determining when to enable dithering, and determining the right clamp value for filters.

)

…entations. (flutter#174219) This makes two refactors to the display list architecture: * The concrete implementations of `DlRuntimeEffect` for skia and impeller are separated, and the impeller implementation put into the `impeller/display_list` target. This makes sure that a client can link against the main `display_list` library without actually pulling in all of impeller. (This is needed for flutter#172314) * The `DrawTextBlob` and `DrawTextFrame` methods are consolidated into one `DrawText` call, and that takes a `DlText` object. The `DlText` object has two implementations, one for skia and one for impeller, and the impeller one is moved into `impeller/display_list` for the same reason mentioned above.

This PR refactors the skwasm renderer to use `DisplayList` objects as its main model objects instead of using Skia objects directly. Then, at render time, we dispatch the display list commands to the skia surface. This is a preparatory step for impeller on web. * Some build rules were reworked in order to allow `DisplayList` to compile via emscripten * Some pieces of the display list library were further refactored to allow us to compile it without actually building and linking the impeller shaders. The two major classes that needed to be separated out were `DlRuntimeEffect` and the text drawing system. * `SkPath` and `SkImage` are still used as the main model objects in skwasm. As of right now, `DisplayList` just thinly wraps these objects, so this is the minimal possible change for now. I will have to refactor this somewhat further when preparing for actual impeller adoption. * Several special cased code paths in skwasm were removed, as they are taken care of by `DisplayList` itself. This includes shadow drawing, determining when to enable dithering, and determining the right clamp value for filters.

github-actions bot added a: text input Entering text in a text field or keyboard related problems engine flutter/engine related. See also e: labels. platform-web Web applications specifically e: impeller Impeller rendering backend issues and features requests labels Jul 17, 2025

eyebrowsoffire changed the title ~~Skwasm display list~~ [skwasm] Port to DisplayList objects Aug 20, 2025

eyebrowsoffire marked this pull request as ready for review August 20, 2025 01:46

eyebrowsoffire requested review from flar and harryterkelsen August 20, 2025 01:46

eyebrowsoffire mentioned this pull request Aug 20, 2025

DL/Geometry engine migration tracking issue #161456

Open

37 tasks

harryterkelsen approved these changes Aug 20, 2025

View reviewed changes

flar requested changes Aug 20, 2025

View reviewed changes

eyebrowsoffire mentioned this pull request Aug 21, 2025

Refactor text and runtime effect to separate skia and impeller implementations. #174219

Merged

eyebrowsoffire force-pushed the skwasm_display_list branch from 99ff77d to 868ad70 Compare August 22, 2025 21:09

flar reviewed Aug 22, 2025

View reviewed changes

flar approved these changes Aug 22, 2025

View reviewed changes

eyebrowsoffire added the autosubmit Merge PR when tree becomes green via auto submit App label Aug 25, 2025

auto-submit bot added this pull request to the merge queue Aug 25, 2025

Merged via the queue into flutter:master with commit 3340cae Aug 25, 2025
186 checks passed

flutter-dashboard bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Aug 25, 2025

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Aug 25, 2025

3340caed8 [skwasm] Port to DisplayList objects (flutter/flutter#172314

226d90d

)

engine-flutter-autoroll mentioned this pull request Aug 25, 2025

Roll Flutter from edd434af3e9d to 3340caed8132 (8 revisions) flutter/packages#9887

Closed

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Aug 25, 2025

3340caed8 [skwasm] Port to DisplayList objects (flutter/flutter#172314

2058bb8

)

engine-flutter-autoroll mentioned this pull request Aug 25, 2025

Roll Flutter from edd434af3e9d to a4cb00ae1509 (9 revisions) flutter/packages#9888

Merged

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Aug 25, 2025

3340caed8 [skwasm] Port to DisplayList objects (flutter/flutter#172314

02a9bbc

)

engine-flutter-autoroll mentioned this pull request Aug 25, 2025

Roll Flutter from edd434af3e9d to b7e2e2a69df7 (11 revisions) flutter/packages#9889

Closed

ksokolovskyi reviewed Sep 5, 2025

View reviewed changes

engine/src/flutter/lib/web_ui/lib/src/engine/skwasm/skwasm_impl/paint.dart Show resolved Hide resolved

navaronbracke mentioned this pull request Sep 6, 2025

[wimp] Impeller for web ☂️ #174980

Open

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Nov 12, 2025

3340caed8 [skwasm] Port to DisplayList objects (flutter/flutter#172314

d83b611

)

eyebrowsoffire deleted the skwasm_display_list branch December 12, 2025 21:51

[skwasm] Port to DisplayList objects #172314

[skwasm] Port to DisplayList objects #172314

Uh oh!

Conversation

eyebrowsoffire commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harryterkelsen left a comment

Choose a reason for hiding this comment

Uh oh!

eyebrowsoffire commented Aug 20, 2025

Uh oh!

flar commented Aug 20, 2025

Uh oh!

eyebrowsoffire commented Aug 20, 2025

Uh oh!

flar commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harryterkelsen commented Aug 20, 2025

Uh oh!

flar 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!

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!

Choose a reason for hiding this comment

Uh oh!

eyebrowsoffire commented Aug 21, 2025

Uh oh!

flar commented Aug 21, 2025

Uh oh!

eyebrowsoffire commented Aug 22, 2025

Uh oh!

flar left a comment

Choose a reason for hiding this comment

Uh oh!

flar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

[skwasm] Port to `DisplayList` objects #172314

[skwasm] Port to `DisplayList` objects #172314

eyebrowsoffire commented Jul 17, 2025 •

edited

Loading

flar commented Aug 20, 2025 •

edited

Loading