Configurable granularity for query change detection
- Langage dominant
- Rust
- Étoiles
- 1.7k
- Forks
- 140
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
Currently, the behavior of the `changed` filter is such that it filters by chunks whose components have been updated. It would be useful if the granularity could be changed based on the user's needs. Here are the useful options I can think of:
* `Chunk`, which exhibits the behavior of the current `changed` filter. The most efficient granularity but also the least accurate.
* `Component`, which filters based on individual components. This could be useful where it is not desirable to iterate over components which have not actually changed. The implementation of this filter brings up some questions:
* A `u32` version for each individual component would have to be stored, which is not ideal for memory usage and cache locality. It may be useful to only store this version where there exists a filter that needs it, although I'm not sure how this could be detected efficiently.
* `ComponentAdded`, which filters on components that have been _added_ to entities since the last query iteration, i.e. components which have been updated using `World::add_component`. I have a use case for this in a project, and its implementation shouldn't be too difficult after the component granularity above is implemented.
This could be implemented by passing a `Granularity` enum to the `changed` filter, or alternatively a different filter function could be implemented for each granularity. I'm not sure which option is superior.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.