IResizeTarget

Remarks

The seam a resize reaches the frame through. A host writes the new size through Resize, which walks the frame and calls Reset on every node that implements this. The shape is IPostProcessTarget's exactly: the compositor owns the walk because it owns the tree, and what a node keeps is the node's own business.

⚠ Most nodes need this and do not implement it. A node that re-declares a graph transient from frame.Size every build already resizes, and so does one that compares a cached extent and reallocates — TemporalAntialiasingRenderer, ReflectionRenderer and HiZPyramid all do, and destroying a texture inside Build is safe because Destroy retires rather than frees. This interface is for the state that cannot be rebuilt that cheaply: a lattice whose shape other objects were constructed against, a temporal chain that a resize invalidates anyway.

⚠ The device is idle when Reset is called, and that is the whole reason the walk exists rather than each node checking its own size. A node that discovers the mismatch inside Build is inside a frame, where the only honest thing left to do is refuse. Resize is called between frames and idles once before the first node is reset, so an implementation may release anything it owns.

⚠ A reset is a camera cut. Everything accumulated starts over — history, placement, readback rings — because reprojecting through a lattice that no longer exists is the quieter of the two wrongnesses and the harder one to see.

Methods (1)

• void Reset()

  Forgets what was laid out against the old size, so the next build lays it again.

Used by (3)

• GraphicsCompositorVixen.Rendering
• ResizeProbeVixen.Engine.Renderer.Tests
• ScreenProbeGatherRendererVixen.Rendering.PostFx