Skip to content

Detach clear() semantics from the Frame #630

@kvark

Description

@kvark

Depends on #161. Deprecates #141.

Asking the renderer to clear a framebuffer is the old-gen way to clear surfaces. There are several issues with that:

  • attachments can have different types. Clearing a RGBA8 (unsigned normalized) target with an integer value is a logical mistake we'd like to disallow.
  • there can be multiple color attachments, which requires expanding ClearData structure and making it less ergonomic.
  • attempt to clear the depth (for example) when there is no depth attachment is (again) a logical error.
  • clearing is not a quad drawing underneath anyway. It may involve running a compute shader on a meta-data sub-surface, for example. As a consequence directX has clearing on the target view level.

When #161 is done, we'll be able to enforce the type of the value to clear with at compile time:

renderer.clear(color_int, 2u);
renderer.clear(color_rgba, (0f32,0.0,0.0,1.0));
renderer.clear(depth_stencil, (0f32, 64u));

The drawback is the need to call clear() on every surface, but considering the killed ClearData, it's going to look way better. The device implementation is free to cache sequential clear() calls, but I expect it to be easier to just clear the surfaces one by one as they come. It's not like clear() is often a bottleneck, and we can always improve it later while preserving the interface.

Potentially, we can (and should) do the same for blitting.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions