Closed Ralith closed 7 months ago
My 2 cents
What I like:
track
is excellentWhat I don't like:
module-level documentation
The module isn't public; I'm just reexporting ChangeTracker
and Changes
at the top level. I'd welcome a succinct doctest for ChangeTracker
to illustrate its use, though.
Looks quite handy, and I like how small and clear an implementation this is! FWIW our project enjoys change tracking in Bevy via DerefMut
marking components dirty (as opposed to running PartialEq
). It most cases it wouldn't matter much, but at least in one one case the component involved is a chonky one, and I suspect that with this implementation, we'd need to layer an additional dirtiness tracking thing on top in order to avoid the cost of PartialEq
.
I suspect there could be a simple workaround; we stash a whole CPU-side collision mesh into a component, and use change detection to trigger its upload to the physics engine. We could probably keep a change counter or a content hash in a separate component, and make the PartialEq
run quickly anyway. For hecs
you could probably just say in a doc "yo don't do change detection on fat structs or else", and recommend a silly workaround like this.
Much like
CommandBuffer
and serialization support, I think this is non-obvious, useful, and self-contained enough to merit inclusion even though it's implemented purely in terms of the public API. I'm interested in feedback on whether this would indeed be useful to people, and on the API design, including the detailed semantics.