🏆 Live Soccer TV: microsoft/WindowsAppSDK/pull/

Mike Crider (codendone) · 2026-07-29T23:12:16Z

Spec proposes new zero-copy accessors for embedded MRT Core resources. Both existing paths copy the bytes on every read even though the .pri is already memory-mapped. The new APIs hand out a read-only, non-owning view instead.

Covers two API layers:

WinRT: ResourceCandidate.ValueAsMemoryBuffer(), an IMemoryBuffer-based alternative to ValueAsBytes.
Flat-C (MRM.h): MrmResourceData2, MrmLoadStringOrEmbeddedResourceNoCopy, MrmLoadStringOrEmbeddedResourceByIndexNoCopy, and MrmFreeResourceData.

ResourceCandidate.ValueAsMemoryBuffer() is the important public API, expected to be used by WinUI and others. The flat-C APIs are support for ResourceCandidate.

azure-pipelines · 2026-07-29T23:12:25Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

Jon Wiswall (jonwis) · 2026-09-24T16:23:52Z

+        /// Zero-copy accessor for embedded/binary resources: returns a read-only IMemoryBuffer that
+        /// projects the resource bytes directly (no copy). The buffer (and any reference created
+        /// from it) pins the backing resource data for its lifetime; Close it when done. Throws for
+        /// Kind != EmbeddedData. Prefer this over ValueAsBytes to avoid a per-call copy.


Why must this throw on "non-embedded data"? Maybe the app has downstream stuff that works better with IMemoryBuffer so "get an IMemoryBuffer" seems nicer. You have all the logic already - if somebody calls this on non-embedded-data value, conjure up a new MemoryBuffer filled with ValueAsBytes... Avoids more conditionals in caller code.

DISCUSSION: Current API returning as BYTEs requires it to be embedded and throws if it isn't. Docs don't say this but code does. Throwing here maintains consistency with existing behavior.

RECOMMEND: Doc bug; fix

Tracking with https://task.ms/64372174

I guess my point was that the consistency is needless. This is a new API, returning a view on data. Why can't it "just work" on all kinds of resource data that has a linear byte representation? Looser rules are usually good. More use cases are usually good.

Howard Kapustein (DrusTheAxe)

API Review: APPROVED

Mike Crider (codendone) · 2026-09-29T22:03:55Z

/azp run

azure-pipelines · 2026-09-29T22:04:15Z

Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions.

Mike Crider (codendone) · 2026-10-02T17:25:14Z

/azp run

azure-pipelines · 2026-10-02T17:25:33Z

Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions.

…r for EmbeddedData (#6660) Implements #6659. # Summary Loading an embedded (`EmbeddedData`) resource from a memory-mapped PRI previously copied the same blob up to three times: twice at load and once more on every read. This change removes all three copies so the bytes can be read directly from the read-only PRI mapping. ## The copies and how each is removed ### Copy 1: load-time heap duplication The loaders (`MRM.cpp`) obtained a `BlobResult` that was already just a *view* into the mapped PRI, then forced a heap copy via `BlobResultReleaseOwnershipBuffer` purely to decouple the returned bytes from the mapping lifetime. **Fix:** New opt-in loaders `MrmLoadStringOrEmbeddedResourceNoCopy` / `...ByIndexNoCopy` return the view directly (`MrmResourceData2.isView == TRUE`) instead of copying. Lifetime is preserved by holding a strong resource-manager reference so the mapping stays alive for the candidate's lifetime. Owned buffers (e.g. decompressed blobs) still come back with `isView == FALSE`. ### Copy 2: construction `ResourceMap.cpp` wrapped the load-time buffer in an `array_view` which the `ResourceCandidate` ctor copied *again* into a `com_array m_blobData`. The original was then released, so it was a transient allocation with an unnecessary memcopy of the entire buffer. **Fix:** Switch to an adopting constructor, where `ResourceCandidate` now takes ownership of the loader buffer (`embedded_resoure_ptr`) rather than re-copying it. For the no-copy (`isView==TRUE`) path, it simply stores the borrowed view. ### Copy 3: every read `ValueAsBytes()` allocated a fresh `com_array` copy on each call. **Fix:** Added `ValueAsMemoryBuffer()` WinRT API, which returns an `IMemoryBuffer` over the single backing buffer/view. This enables zero copies per read. WinUI will be updated to use this API. (`ValueAsBytes()` is unchanged for compatibility.) ## ABI safety The existing APIs are unchanged. New flat-C APIs in `MRM.h` enable a non-copy view access to embedded data. The new `ResourceCandidate.ValueAsMemoryBuffer()` provides that access via the WinRT `ResourceCandidate` type. ## Testing New TAEF unit tests cover view vs. owned results, strings-are-not-views, by-index loading, and `MrmFreeResourceData` ownership semantics. The changes have also been tested in a WinUI app on a private build using the new `ValueAsMemoryBuffer()` API.

….ValueAsMemoryBuffer for EmbeddedData (#6857) * Implement new zero-copy accessor ResourceCandidate.ValueAsMemoryBuffer for EmbeddedData (#6660) Implements #6659. # Summary Loading an embedded (`EmbeddedData`) resource from a memory-mapped PRI previously copied the same blob up to three times: twice at load and once more on every read. This change removes all three copies so the bytes can be read directly from the read-only PRI mapping. ## The copies and how each is removed ### Copy 1: load-time heap duplication The loaders (`MRM.cpp`) obtained a `BlobResult` that was already just a *view* into the mapped PRI, then forced a heap copy via `BlobResultReleaseOwnershipBuffer` purely to decouple the returned bytes from the mapping lifetime. **Fix:** New opt-in loaders `MrmLoadStringOrEmbeddedResourceNoCopy` / `...ByIndexNoCopy` return the view directly (`MrmResourceData2.isView == TRUE`) instead of copying. Lifetime is preserved by holding a strong resource-manager reference so the mapping stays alive for the candidate's lifetime. Owned buffers (e.g. decompressed blobs) still come back with `isView == FALSE`. ### Copy 2: construction `ResourceMap.cpp` wrapped the load-time buffer in an `array_view` which the `ResourceCandidate` ctor copied *again* into a `com_array m_blobData`. The original was then released, so it was a transient allocation with an unnecessary memcopy of the entire buffer. **Fix:** Switch to an adopting constructor, where `ResourceCandidate` now takes ownership of the loader buffer (`embedded_resoure_ptr`) rather than re-copying it. For the no-copy (`isView==TRUE`) path, it simply stores the borrowed view. ### Copy 3: every read `ValueAsBytes()` allocated a fresh `com_array` copy on each call. **Fix:** Added `ValueAsMemoryBuffer()` WinRT API, which returns an `IMemoryBuffer` over the single backing buffer/view. This enables zero copies per read. WinUI will be updated to use this API. (`ValueAsBytes()` is unchanged for compatibility.) ## ABI safety The existing APIs are unchanged. New flat-C APIs in `MRM.h` enable a non-copy view access to embedded data. The new `ResourceCandidate.ValueAsMemoryBuffer()` provides that access via the WinRT `ResourceCandidate` type. ## Testing New TAEF unit tests cover view vs. owned results, strings-are-not-views, by-index loading, and `MrmFreeResourceData` ownership semantics. The changes have also been tested in a WinUI app on a private build using the new `ValueAsMemoryBuffer()` API. * Added containment

Mike Crider (codendone) added 2 commits July 29, 2026 15:24

Add spec.

8206501

A few tweaks

6f33b36

microsoft-github-policy-service Bot added the needs-triage label Jul 29, 2026

Merge branch 'main' into user/codendone/apiSpecMRTmemoryUsage

59789a0

Mike Crider (codendone) mentioned this pull request Jul 30, 2026

Implement new zero-copy accessor ResourceCandidate.ValueAsMemoryBuffer for EmbeddedData #6660

Merged

Jon Wiswall (jonwis) reviewed Sep 24, 2026

View reviewed changes

Raymond Chen (oldnewthing) reviewed Sep 24, 2026

View reviewed changes

Mike Crider (codendone) commented Sep 25, 2026

View reviewed changes

Comment thread specs/mrtcore/ZeroCopyResourceData.md Resolved

Howard Kapustein (DrusTheAxe) approved these changes Sep 25, 2026

View reviewed changes

Mike Crider (codendone) added 2 commits September 29, 2026 13:16

Apply API review feedback.

dcbdd26

Some tweaks

4b3fd36

Jesse Collins (JesseCol) approved these changes Oct 1, 2026

View reviewed changes

Merge branch 'main' into user/codendone/apiSpecMRTmemoryUsage

db058ee

Mike Crider (codendone) merged commit 888bfbd into main Oct 2, 2026
51 checks passed

Mike Crider (codendone) deleted the user/codendone/apiSpecMRTmemoryUsage branch October 2, 2026 23:14

Mike Crider (codendone) mentioned this pull request Oct 5, 2026

Fix embedded MRT resource memory lifetime microsoft/microsoft-ui-xaml#12128

Merged

5 of 13 tasks

Mike Crider (codendone) mentioned this pull request Oct 12, 2026

[2.0-experimental] Implement new zero-copy accessor ResourceCandidate.ValueAsMemoryBuffer for EmbeddedData #6857

Merged

Conversation

Mike Crider (codendone) commented Jul 29, 2026

Uh oh!

azure-pipelines Bot commented Jul 29, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Jon Wiswall (jonwis) Sep 24, 2026

Choose a reason for hiding this comment

Uh oh!

Howard Kapustein (DrusTheAxe) Sep 25, 2026

Choose a reason for hiding this comment

Uh oh!

Mike Crider (codendone) Sep 29, 2026

Choose a reason for hiding this comment

Uh oh!

Jon Wiswall (jonwis) Oct 4, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Howard Kapustein (DrusTheAxe) left a comment

Choose a reason for hiding this comment

Uh oh!

Mike Crider (codendone) commented Sep 29, 2026

Uh oh!

azure-pipelines Bot commented Sep 29, 2026

Uh oh!

Mike Crider (codendone) commented Oct 2, 2026

Uh oh!

azure-pipelines Bot commented Oct 2, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants