Proposing changes to StorageBufferHandle/UniformBufferHandle that (IMO) can catch some potential bugs and are a bit clearer.
The Bind()/Update() methods and the event data transmitted for buffer writes used non-const pointers, despite the fact that these are just sources for memcpy. I think we should be more explicit about the fact that the input data won't be modified. The event receiver doesn't know anything about the underlying data anyway, so it should never be modifying it.
The interface for these can take a range, rather than a pointer/size, and pass along the pointer/size from the range to the implementation, minimizing bugs at the call site (maybe you have two vectors, and you accidentally call data on one and size on another - I have done this sort of thing before).
The fact that there is a memcpy happening behind the scenes isn't explicit (arguably you could intuit that its happening), and nobody is verifying the type is safe to copy. In practice, the involved types are likely to be trivially copyable, but we can guarantee that at compile-time.
The per-frame and static implementations can be combined pretty simply.
Proposing changes to
StorageBufferHandle/UniformBufferHandlethat (IMO) can catch some potential bugs and are a bit clearer.Bind()/Update()methods and the event data transmitted for buffer writes used non-const pointers, despite the fact that these are just sources formemcpy. I think we should be more explicit about the fact that the input data won't be modified. The event receiver doesn't know anything about the underlying data anyway, so it should never be modifying it.memcpyhappening behind the scenes isn't explicit (arguably you could intuit that its happening), and nobody is verifying the type is safe to copy. In practice, the involved types are likely to be trivially copyable, but we can guarantee that at compile-time.