Maps the runtime's per-kind resource slots to the identifiers the browser side knows them by. More...
#include "donner/gpu/browser/BrowserObjectTable.h"
Public Member Functions | |
| BrowserObjectInsertion | insert (BrowserObjectKind kind, uint32_t slotIndex) |
Mints an identifier for slotIndex of kind and records the mapping. | |
| std::optional< BrowserObjectId > | find (BrowserObjectKind kind, uint32_t slotIndex) const |
Returns the identifier recorded for (kind, slotIndex), or nullopt when the slot holds none. | |
| std::optional< BrowserObjectId > | remove (BrowserObjectKind kind, uint32_t slotIndex) |
Removes and returns the identifier recorded for (kind, slotIndex), or nullopt when the slot holds none. | |
| size_t | liveCount () const |
| Number of slots currently holding an identifier, across every kind. | |
| std::vector< std::pair< BrowserObjectKind, BrowserObjectId > > | takeAll () |
| Empties the table and returns everything it held, so teardown can release each browser object exactly once. | |
Static Public Attributes | |
| static constexpr uint32_t | kMaxSlotIndex = (1u << 20) - 1 |
| Largest slot index this table will store. | |
Maps the runtime's per-kind resource slots to the identifiers the browser side knows them by.
The runtime addresses a resource by (kind, slot index) and reuses a slot once its occupant is gone; the browser side addresses the same object by an identifier that is never reused. This table is the single place the two namings meet, so a stale identifier cannot re-enter circulation through slot reuse.
Identifiers are drawn from one counter shared by every kind, which keeps an identifier meaningful on its own: a value that names a buffer never also names a texture, so the kind check the browser side performs is a genuine second check rather than a restatement of the first.
| std::optional< BrowserObjectId > donner::gpu::browser::BrowserObjectTable::find | ( | BrowserObjectKind | kind, |
| uint32_t | slotIndex ) const |
Returns the identifier recorded for (kind, slotIndex), or nullopt when the slot holds none.
| kind | Kind of object to look up. |
| slotIndex | Runtime slot index of the resource. |
| BrowserObjectInsertion donner::gpu::browser::BrowserObjectTable::insert | ( | BrowserObjectKind | kind, |
| uint32_t | slotIndex ) |
Mints an identifier for slotIndex of kind and records the mapping.
A slot that still holds an identifier has its old one displaced rather than refused. Most resource kinds are released through a destruction hook before their slot is reused, so nothing is ever displaced for them; a surface has no such hook, because the platform object it presents to outlives the runtime's handle, so its slot can be reused while this table still names the browser object it used to hold. Reporting the displaced identifier lets the caller release it on the browser side in that case, and makes the common case where nothing was displaced visible rather than assumed.
Returns a null BrowserObjectInsertion::id if the identifier space is exhausted or slotIndex is beyond kMaxSlotIndex; callers fail closed on that rather than proceeding with an identifier the browser side would refuse.
| kind | Kind of object occupying the slot. |
| slotIndex | Runtime slot index of the resource. |
| std::optional< BrowserObjectId > donner::gpu::browser::BrowserObjectTable::remove | ( | BrowserObjectKind | kind, |
| uint32_t | slotIndex ) |
Removes and returns the identifier recorded for (kind, slotIndex), or nullopt when the slot holds none.
The identifier is not returned to circulation.
| kind | Kind of object to remove. |
| slotIndex | Runtime slot index of the resource. |
| std::vector< std::pair< BrowserObjectKind, BrowserObjectId > > donner::gpu::browser::BrowserObjectTable::takeAll | ( | ) |
Empties the table and returns everything it held, so teardown can release each browser object exactly once.
Entries come back grouped by kind in enumerator order and by ascending slot within a kind, which makes teardown order deterministic and therefore reproducible in a test.
|
staticconstexpr |
Largest slot index this table will store.
Per-kind storage is a dense vector indexed by slot, so a slot index decides an allocation size. The runtime allocates slots densely from zero and its resource limits are far below this, so a slot index anywhere near it did not come from the runtime; refusing it keeps a wrong index from becoming a large allocation.
1.15.0 