What if we store dirtiness on the elements and the dirtiness query is recursive and can take a list of UiElementNames as exceptions (we can stop recurring if we encounter an element in the list)?

Sounds like another tree walk? That would be unfortunate.

It's true, but we'd only have to do it in tests when we're trying to check if the scene (minus controller subtree) are clean.

Did you mean that we would store quiescence on the elements? I don't think dirtiness would be test-only, but quiescence would be.

I'm suggesting we have one concept for dirtiness and that it would represent "did I change". It would be local to the element.

With my proposal, the difference between the two cases outlined in the original description would be in the query issued. If you care about whether anything at all in the  scene has changed you can ask the IsDirty routine to do a walk w/ no exceptions. If you don't care about the controller subtree, you could issue the same query but pass kControllerGroup in as an exception to skip that subtree.

Sure, but now you're proposing an additional tree-walk that isn't test-only.

I think we should still maintain the concept of global dirtiness as computed by OnBeginFrame. We could, in addition to this, store a dirty bit on each element so that tests could check which elements are dirty and exclude the ones it doesn't care about.

But I think an even better option would be to have a quiescence bit on each element in addition to our current global dirtiness. Then each element can decide what it means to be quiescent. For example, the controller would dirty the scene every frame, but be quiescent if it hasn't moved very much, avoiding the rendering issues but still allowing testing.

It's been a while since I looked at this code, but it looks like we now have a world_space_transform_dirty_ bit to avoid unnecessary work in the UpdateWorldSpaceTransform pass.

I guess we don't really need the global dirtiness bit anymore, though I'm sad to see it go :P

Making it a tree walk for tests only sounds fine.

Actually, there is a problem with that - I could imagine some tests wanting to move/animate the controller and running into problems where the only thing that gets dirtied is the controller and we report quiescence too early. Might be unavoidable that the controller maintains a notion of insignificant vs significant movement.

I don't really know what to do with this, or why it matters. Feel free to reopen with some more context.

This is pretty much obsolete now that we can mock out the controller position during tests.