CNA-BUG-227: StubTextureRenderer's comment says GetData() is accepted and discarded, but the inherited default refuses the read

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

✓

Evidence basis: source-verified at the pinned commit; tests exist (not executed for this page). Claims on this page were checked by reading the CNA source at commit 009d40f5; unless a sentence says otherwise, nothing here was built or executed. Nothing on this page was executed unless the Evidence section says so.

The class comment on StubTextureRenderer says SetData()/GetData() are accepted no-op defaults, while the ITextureRenderer::GetData default it inherits returns false, which the shared Texture2D layer turns into NotSupportedException.

Identifier
CNA-BUG-227
Category
Bug
Subsystem
Documentation & release tooling
Status
Open
Verified against
CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)
Severity
Low (a triage suggestion, not a project priority)
Evidence basis
Source-verified: read at TARGET, not executed
Tests touching this area
Yes: see Current tests
Affected contract
Maintainer comment on CNA::Internal::Renderers::Stub::StubTextureRenderer

Expected behaviour

The class comment describes what the STUB texture does with uploads and reads.

Actual behaviour at TARGET

StubRenderer.hpp: "Stores only width/height -- no pixel data of any kind; SetData()/GetData() are accepted (inherited no-op defaults) and simply discarded." Uploads are indeed discarded, but ITextureRenderer::GetData(level, x, y, w, h, data, dataLength) defaults to false ("this renderer read nothing back"), and Texture2D raises System::NotSupportedException on false wherever it needs the renderer's copy (render-target content, partial updates, block-compressed data). Reads are refused, not accepted.

Source locations

Evidence

Checked by reading at 009d40f5; not executed. The interface comment explains why the default became a refusal: a silent no-op default "fabricated a complete, uniformly transparent-black frame". Only the STUB comment is stale; behaviour follows the interface.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Current tests

Stub_Smoke uploads a texture but never reads one back; CNA's Stub lane records classify the shared suites' cube-texture refusals as the expected STUB taxonomy.

Regression test

No test is needed; correct the comment to say reads are refused through the interface default.

Blast radius

Maintainers reading the STUB renderer. No behaviour is affected.

Workaround

No workaround is known.

The same subject is explained at several altitudes. These are the neighbouring pages at each one.

Known issues
Bug index