Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.

Submission-bound prepared pixels, development version 2

Prepared.2 lets an independent producer prepare an owned component from Packet.1 before the first native draw. It is separate from the unchanged draft3 pixel ABI. Publishing prepared pixels supplies intent; the native packet plan, semantic coverage, actual terminal, target, capabilities, identity and freshness checks still decide every omission. Production packet capabilities remain zero while native integration and acceptance are unfinished.

The mapping is Local\OpenHoops.Presentation.Prepared.2.<channel-token>, with .mutex for individual publications, .producer for one writing thread and .selected for persistent route selection. The native Host creates all four objects. The producer opens the selection semaphore with release-only rights; the Host consumes its signal into a private latch while holding the publication mutex. Writable header fields cannot undo that selection. A client verifies the exact game PID and process creation time before opening them. This uses the pixel-channel token; the public API bearer token never crosses the mapping. The producer opens only the documented shared mapping and process query/synchronization handles.

The independent layouts are in native/presentation/packet-prepared.hpp and framework/packet_prepared.py. The 64-byte header describes 64 fixed metadata entries, each 248 bytes, followed by a 64 MiB pixel pool. Offsets are relative to that pool. Metadata and payload changes occur under the publication mutex; the Host uses a zero-wait read and copies its selected payload before releasing it. A busy or abandoned publication retains native output. Abandonment clears unselected entries without renewing a previous deadline.

Each entry binds all of the following:

• Opaque ledger domain, slot, incarnation, run nonce, native epoch and device generation.
• Owner, native root ID, submission serial and revision.
• The registry resource token and full verified native-asset SHA256.
• The submission's exact end-sampled context, including original API sample and timestamp.
• Original production/deadline times, canvas, rectangle, declared dependencies and artwork mode.

Native addresses are excluded. Equal score text or a reused allocation cannot match a different packet/submission. The adapter resolves the full asset digest from its verified registry. The sampled context must equal the private sealed submission; a client cannot refresh it with a newer observation. Copied native text, sampled facts and current draw authority remain distinct.

There are three artwork modes. pixels contains tightly packed, premultiplied BGRA bytes for a cropped rectangle. solid contains a premultiplied ARGB color and rectangle, with no pixel payload; the Host uses a 1×1 texture. hide has no rectangle or artwork. Hiding still needs independent native hide capability and semantic coverage. A package's dependencies cannot remove the adapter minimum.

The writer signals selection before changing any publication. This selects prepared entries for owned packet graphics for the rest of that channel token. A missing, expired or mismatched entry then falls back to native output. It cannot borrow a draft3 owner plane. Draft3 remains the compatibility path before prepared selection begins and continues carrying unowned overlays. Writer.clear() clears bank entries and preserves prepared mode; existing Host copies and pins retain their original guards and deadlines. A new token starts a new session.

The Host keeps at most 16 immutable texture versions with a combined 64 MiB allocation bound. Identical pixels can share a version across packet identities, but each identity is validated independently. A pinned version is never overwritten; idle versions can be rewritten or evicted. Exhaustion falls back to native output. Retirement releases the packet's pins, and Reset releases all default-pool references before forwarding the native Reset. Reentrant device-loss notification defers resource destruction until the active driver operation exits; Reset itself excludes packet retirement until its original callback returns. The CPU cache has the same bound plus one bounded upload staging buffer.

The first omission chooses one immutable entry and composition anchor for that owner and packet. Later omissions keep that entry's original context/deadline; a newer publication cannot renew it. Live identity, generation, primary target, pause/replay, coherent observation and both 100 ms age bounds remain required. Each terminal also commits through the revocation fence. Previously committed terminal work may finish after withdrawal; subsequent terminals remain native. This does not provide atomic rollback of pixels already submitted to D3D.

The Python client entry points are entry_from(packet, submission, ...), Writer.publish(entry, pixels), Writer.clear() and Writer.close(). The factory requires a complete decoded Packet.1 submission and its original end sample. The writer freezes buffers before locking, allocates by bounded first-fit/oldest eviction, and checks the owning process remains alive. It clears uncommitted shared metadata before reusing its payload, then publishes one changed entry without copying the complete pool. Entries removed from the pool do not alter textures the Host has already pinned.

The supplied worker opts in with --transport 3 --packet-preparation. This path currently prepares version-5 packages whose owned scenes use native_draw. It processes at most 16 fresh, usable jobs per loop, renders only the requested owner, retains up to 64 completed submission keys, and keeps at most eight public snapshots. A snapshot history hit retains its original receipt time and age, and is unavailable after a current public identity or health change. Unmapped, ambiguous or unknown-opacity submitted text withholds content preparation. Measurement-only, empty and copied zero-opacity text retain their explicit exclusions. Native sequence/lifecycle cues and manual owned scenes require their separate integration; availability here is not an entry or completion event.

The actual tests distinguish portable metadata/allocator checks, original-x86 packet/leaf fixtures, Windows software rasterization, shared mapping consumers, Host COM fixtures and native-game acceptance. Passing a software or COM fixture does not certify native pixels, complete resource lifetime, callback coverage, all 31 active scopes or the 22 retained-native categories. No network artwork, public/stable package promotion or full-framework acceptance is implied.