forked from StudioInfinity/dyna3
Flag our workaround for a Sycamore batching bug
Add a reminder to remove the workaround once the bug is fixed.
This commit is contained in:
parent
c73008d702
commit
03d6cf0687
1 changed files with 10 additions and 0 deletions
|
@ -18,6 +18,16 @@ pub fn AddRemove() -> View {
|
||||||
// this call is batched to avoid redundant realizations.
|
// this call is batched to avoid redundant realizations.
|
||||||
// it updates the element list and the regulator list,
|
// it updates the element list and the regulator list,
|
||||||
// which are both tracked by the realization effect
|
// which are both tracked by the realization effect
|
||||||
|
/* TO DO */
|
||||||
|
// it would make more to do the batching inside
|
||||||
|
// `insert_element_default`, but that will have to wait
|
||||||
|
// until Sycamore handles nested batches correctly.
|
||||||
|
//
|
||||||
|
// https://github.com/sycamore-rs/sycamore/issues/802
|
||||||
|
//
|
||||||
|
// the nested batch issue is relevant here because the
|
||||||
|
// assembly loaders in the test assembly chooser use
|
||||||
|
// `insert_element_default` within larger batches
|
||||||
state.assembly.insert_element_default::<Sphere>();
|
state.assembly.insert_element_default::<Sphere>();
|
||||||
});
|
});
|
||||||
}
|
}
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue