-
Notifications
You must be signed in to change notification settings - Fork 535
Closed
Description
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
ClearDatastructure 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.