ResourcePolicy

Namespace: Ava3D

public sealed class ResourcePolicy

How long a view keeps textures and meshes on the card once nothing is drawing them, how much it may keep, and how much of each frame it spends copying new ones up.

Every view on the same graphics device shares one set of resident resources — a texture uploaded for one view is drawn by the next without a second upload — and one policy governs that set. Where views on a device disagree, the most permissive of them wins on each field separately: the largest budget, the longest grace, the most upload time. A view that wants less than another cannot take resources away from it, which is the only rule under which two views can share a card without knowing about each other.

Nothing here says when a resource is loaded. A texture is decoded the first frame something draws it, off the render thread, and copied to the card within ResourcePolicy.UploadMillisecondsPerFrame. To have a scene's resources on the card before it is shown, see Ava3DView.PrepareAsync; to keep a scene's resources whatever this policy says, see Ava3DView.Retain.

Properties

Member Description

Member	Description
`long BudgetBytes { get; set; }`	How many bytes of textures, meshes and instance buffers may stay resident on the device. Zero — the default — takes the device's own recommendation: half of what Metal reports as its working set, half of the largest device-local heap on Vulkan (or its budget, where `VK_EXT_memory_budget` is there), 512 MB on OpenGL, which has no way to ask, and 256 MB of decoded pixels for the software renderer. Past the budget, the least recently used resource goes first, and a resource any view is currently drawing never goes. Under it, nothing goes until `ResourcePolicy.GraceSeconds` after it was last drawn.
`double GraceSeconds { get; set; }`	How long a resource nothing is drawing stays resident while the device is under budget. Five seconds by default: long enough that a scene switched away from and back does not upload again, short enough that a scene left behind does not hold its memory for the life of the process. Zero evicts on the next frame after a resource stops being drawn — today's behaviour, one scene swap later. A resource pinned by `Ava3DView.Retain` is not subject to it.
`double UploadMillisecondsPerFrame { get; set; }`	How many milliseconds of each frame the render thread may spend copying decoded textures to the device. Two by default. Decoding, resizing and building mip chains never count against it — those happen on the thread pool — so this is the cost of `memcpy` into device memory and nothing else. One copy is always made however large it is, so a single oversize image may overrun the figure once.

long BudgetBytes { get; set; }

How many bytes of textures, meshes and instance buffers may stay resident on the device. Zero — the default — takes the device's own recommendation: half of what Metal reports as its working set, half of the largest device-local heap on Vulkan (or its budget, where VK_EXT_memory_budget is there), 512 MB on OpenGL, which has no way to ask, and 256 MB of decoded pixels for the software renderer.

Past the budget, the least recently used resource goes first, and a resource any view is currently drawing never goes. Under it, nothing goes until ResourcePolicy.GraceSeconds after it was last drawn.

double GraceSeconds { get; set; }

How long a resource nothing is drawing stays resident while the device is under budget. Five seconds by default: long enough that a scene switched away from and back does not upload again, short enough that a scene left behind does not hold its memory for the life of the process.

Zero evicts on the next frame after a resource stops being drawn — today's behaviour, one scene swap later. A resource pinned by Ava3DView.Retain is not subject to it.

double UploadMillisecondsPerFrame { get; set; }

How many milliseconds of each frame the render thread may spend copying decoded textures to the device. Two by default. Decoding, resizing and building mip chains never count against it — those happen on the thread pool — so this is the cost of memcpy into device memory and nothing else. One copy is always made however large it is, so a single oversize image may overrun the figure once.