Refactor per-draw render data allocations with a binary opcode stream by ZehMatt · Pull Request #21366 · AvaloniaUI/Avalonia

ZehMatt · 2026-05-14T21:06:08Z

This work stems from the comment #20885 (comment) , this is not exactly how WPF is doing it, the unsafe keyword for example has been avoided, also I wasn't a huge fan of where #20885 was going.

What does the pull request do?

Replaces the render data representation. Until now every DrawingContext draw or push call recorded a heap-allocated node object (RenderDataLineNode, RenderDataRectangleNode, the push nodes, …) into a PooledInlineList.
This PR replaces those objects with a flat binary opcode stream plus a resource table. This is the approach WPF uses for its MILCMD render data.

It is an internal change: no public API, rendering output, or behaviour changes.

What is the current behavior?

Every recorded draw/push allocates a node object. For a visual whose content changes each frame (animations, custom-drawn controls) that is one GC-tracked allocation per draw call, every frame - gen0 churn proportional to the draw-call count.

What is the updated/expected behavior with this PR?

Render data is recorded as a byte[] opcode stream plus a resource table. Recording, server-side replay, hit-testing and bounds calculation all walk the byte stream directly, with no per-draw object allocation.

Rendering, hit-testing and visual bounds are unchanged, covered by the render-data contract tests merged in #21341 and the existing render tests, plus new unit tests added here, resource table, the three walkers, serialization round-trip, deep-nesting fallback.

The changes were measured locally with a stress test of ~9k draw calls per frame using mixed primitives.
master:

Draw calls/frame:     9,271
Measured window:      10.0s
Frames rendered:      404
Average FPS:          40.4
Total allocated:      498.74 MB
Allocated per frame:  1264.1 KB
Allocated per second: 49.85 MB/s
GC gen0 / gen1 / gen2: 83 / 83 / 0
Managed heap (end):   9.7 MB

PR:

Draw calls/frame:     9,271
Measured window:      10.0s
Frames rendered:      403
Average FPS:          40.3
Total allocated:      22.99 MB
Allocated per frame:  58.4 KB
Allocated per second: 2.30 MB/s
GC gen0 / gen1 / gen2: 4 / 0 / 0
Managed heap (end):   9.7 MB

The code for the test: https://gist.github.com/ZehMatt/6d033ecd016335b8b02f649a6666286c , its quite evident that this saves quite a bit of memory, in my testing there was no GC pressure anymore in the rendering path, now the major contributor to GC cycles is elsewhere.

How was the solution implemented (if it's not obvious)?

New types under Rendering/Composition/Drawing/:

RenderDataOpcode - one value per draw/push operation, plus Pop.
RenderDataWriter / RenderDataReader - the byte codec. Blittable payload structs (Point, Rect, RoundedRect, Matrix, BoxShadow, RenderOptions, …) are bulk-copied through a where T : unmanaged generic helper; the constraint is a compile-time guard against a payload type silently becoming non-blittable.
RenderDataResources - interns the non-blittable operands (brushes, pens, geometries, bitmaps, custom ops) to int handles referenced from the payloads.
RenderDataStream - owns the opcode stream and resource table, with the recording API and the replay / hit-test / bounds walkers. Push/Pop are inline opcodes; the walkers stackalloc their scope stack, sized from a max-push-depth tracked while
recording.

The four consumers were switched over: RenderDataDrawingContext (recording), CompositionRenderData (client + hit-testing + serialization), ServerCompositionRenderData (server replay + bounds), ImmediateRenderDataSceneBrushContent and the old node classes and IRenderDataItem deleted.

The branch is structured as small standalone commits, so it should be easy to review the changes commit by commit.

Checklist

Added unit tests (if possible)?
Added XML documentation to any related classes?
Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Fixed issues

Addresses some points of #19363 in regards to rendering.

Final Note

I'm glad that #20885 wasn't merged, this is definitely the cleaner solution to the problem and its backed up by the data.

avaloniaui-bot · 2026-05-14T21:38:57Z

You can test this PR using the following package version. 12.1.999-cibuild0065403-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

avaloniaui-bot · 2026-05-15T14:28:28Z

You can test this PR using the following package version. 12.1.999-cibuild0065435-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

kekekeks

Haven't had a thorough read yet, some questions.

ZehMatt · 2026-05-17T21:45:17Z

I have addressed the review comments, let me know if there is anything else you would like to be changed.

avaloniaui-bot · 2026-05-17T22:20:56Z

You can test this PR using the following package version. 12.1.999-cibuild0065455-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

avaloniaui-bot · 2026-05-19T16:16:59Z

You can test this PR using the following package version. 12.1.999-cibuild0065593-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

avaloniaui-bot · 2026-05-20T17:36:45Z

You can test this PR using the following package version. 12.1.999-cibuild0065629-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

ZehMatt · 2026-05-31T00:55:27Z

I've rebased the PR and added serialization for the effect support. It would be nice to know if anything else needs to be changed, I don't want to keep up with rebasing and plucking in things that are being added in the master branch.

avaloniaui-bot · 2026-05-31T01:23:01Z

You can test this PR using the following package version. 12.1.999-cibuild0065909-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

maxkatz6 · 2026-06-01T10:47:45Z

+        if (_buffer is null)
+            _buffer = ArrayPool.Shared.Rent(Math.Max(required, 256));
+        else if (_buffer.Length < required)
+        {
+            var grown = ArrayPool.Shared.Rent(Math.Max(required, _buffer.Length * 2));
+            Array.Copy(_buffer, grown, _length);
+            ArrayPool.Shared.Return(_buffer);
+            _buffer = grown;
+        }


I don't have a preference here, just a question. Should we use shared pool here or create a dedicated one for rendering? Dedicated one can be enough, if it's only reused between frames, and not globally in the app

The benefit of shared is that it can re-use memory and keep the memory footprint small across the app for when things just need a scratch buffer, but I also don't exactly have a strong preference here assuming this question was directed at me?

Note that a shared pool has an app-wide cap of memory that could be returned into it without being GC-freed. This might have unexpected effects in actual apps where some other library uses the same pool, we'll essentially fall back to always allocate.

This is probably out of scope of this PR, but we could use the same approach as with our batch streams, where we track sustained usage counters over time and free memory after some time passes.

Another thing we could explore here is ref-counted native memory, but, again, out of scope.

Makes sense, I can follow up on this if this if/when PR lands, for now I somewhat doubt someone will ever run into the issue of pooled memory exhaustion, if this happens then quite frankly it's more of a problem that it's being used wrong.

avaloniaui-bot · 2026-06-01T12:40:48Z

You can test this PR using the following package version. 12.1.999-cibuild0065939-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

avaloniaui-bot · 2026-06-04T23:31:21Z

You can test this PR using the following package version. 12.1.999-cibuild0066047-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

MrJul

Substantial gains, comprehensive tests, clean code, this is a great PR. I've reviewed it and this looks very good to me. I've left a couple of very minor comments.

First step of the Drawing/Nodes binary stream refactor.

Encodes the opcode stream field-by-field via BinaryPrimitives to avoid unsafe and blittability assumptions.

avaloniaui-bot · 2026-06-12T17:46:34Z

You can test this PR using the following package version. 12.1.999-cibuild0066383-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

MrJul

LGTM!

ZehMatt mentioned this pull request May 14, 2026

Pool render data nodes to reduce per-frame GC pressure #20885

Closed

MrJul added enhancement area-perf area-rendering labels May 15, 2026

kekekeks reviewed May 17, 2026

View reviewed changes

kekekeks added this to the 12.1 milestone May 30, 2026

ZehMatt force-pushed the refactor/render-data-binary-stream branch from 0b20c25 to 7fb34d8 Compare May 31, 2026 00:51

maxkatz6 reviewed Jun 1, 2026

View reviewed changes

MrJul previously approved these changes Jun 12, 2026

View reviewed changes

Comment thread src/Avalonia.Base/Rendering/Composition/Drawing/RenderDataStream.cs

Comment thread src/Avalonia.Base/Rendering/Composition/Drawing/RenderDataReader.cs Outdated

Comment thread src/Avalonia.Base/Rendering/Composition/Drawing/RenderDataWriter.cs Outdated

ZehMatt added 11 commits June 12, 2026 20:06

Add render data opcode enum

70453c1

First step of the Drawing/Nodes binary stream refactor.

Add render data resource table

bb88e2e

Add render data stream writer and reader

919fa73

Encodes the opcode stream field-by-field via BinaryPrimitives to avoid unsafe and blittability assumptions.

Add RenderDataStream with recording and replay

0d6f055

Add hit-test walker to RenderDataStream

2ec289d

Add bounds walker to RenderDataStream

9fc513b

Add render data stream serialization

ca0c113

Switch render data to the binary stream

4fa9cc2

Move node level test coverage to the stream

9dc78d6

Delete the render data node classes

592718d

Small optimization, stackalloc the render data walker scope stacks

138daf4

ZehMatt added 5 commits June 12, 2026 20:06

Optimize serialization for blittable types

9415a91

Encode render data via payload structs, add render data visitor

1b49485

Rename RenderDataResources.Add to AppendDeserialized

37aa79e

Add effect support to render data stream

8d14e58

Simplify render data read/write with MemoryMarshal

953f823

ZehMatt dismissed MrJul’s stale review via 953f823 June 12, 2026 17:09

ZehMatt force-pushed the refactor/render-data-binary-stream branch from b97057b to 953f823 Compare June 12, 2026 17:09

MrJul approved these changes Jun 15, 2026

View reviewed changes

MrJul added this pull request to the merge queue Jun 15, 2026

Merged via the queue into AvaloniaUI:master with commit aa1fcb4 Jun 15, 2026
11 checks passed

ZehMatt deleted the refactor/render-data-binary-stream branch June 15, 2026 13:33

hez2010 mentioned this pull request Jul 27, 2026

[12.1 Regression] Animated geometry does not hit test correctly #21801

Open

ZehMatt mentioned this pull request Aug 4, 2026

Improve High-Frequency Rendering by enhancing allocations for GC #19363

Open

Conversation

ZehMatt commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does the pull request do?

What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

Fixed issues

Final Note

Uh oh!

avaloniaui-bot commented May 14, 2026

Uh oh!

avaloniaui-bot commented May 15, 2026

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ZehMatt commented May 17, 2026

Uh oh!

avaloniaui-bot commented May 17, 2026

Uh oh!

avaloniaui-bot commented May 19, 2026

Uh oh!

avaloniaui-bot commented May 20, 2026

Uh oh!

ZehMatt commented May 31, 2026

Uh oh!

avaloniaui-bot commented May 31, 2026

Uh oh!

maxkatz6 Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

ZehMatt Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

kekekeks Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

ZehMatt Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

avaloniaui-bot commented Jun 1, 2026

Uh oh!

avaloniaui-bot commented Jun 4, 2026

Uh oh!

MrJul left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

avaloniaui-bot commented Jun 12, 2026

Uh oh!

MrJul left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ZehMatt commented May 14, 2026 •

edited

Loading

kekekeks left a comment •

edited

Loading