Whenever a state changes, we essentially iterate over all regions to sort/grow them.

We can optimize that by introducing another abstraction, which iirc was part of the dg2 work by rivers.

That is introuce the concept of a "container", that handles the sorting/layout of all regions that are attached to the same frame and provides api to add/remove regions to themselve.

So if a state changes: If the region stays in the ame container we only need to sort/layout that container. And otherwise remove it from the previous container and add it to the next.

Just to clarify on the specific strategy I had been going for, the dynamic group asks for each child (on the usual activate/state change), 'where' they want to be distributed to

• this 'where' takes the form of (up to) 3 values:
  1. containerType - string describing what kind of thing child wants to anchor to - could be self, unit, nameplate, etc, to anchor to the dgroup region, a unit frame, a nameplate, etc
  2. anchorId - value specifying which thing to anchor to, given the type. For self, this only makes sense to be nil or the WA nil special (an empty string), but for unit a unitId would be the obvious choice
  3. containerId - optional string (default is empty string) which would allow multiple containers to be anchored to the same thing from a single dynamic group. I largely didn't see any immediate use cases from this but it seemed like exactly the sort of thing that would immediately become useful once the public got their hands on it.
• Children which have identical contianerType, anchorId, containerId are treated as being in the same group, so that updates to the state or addition/removal of a state from that container triggers a resort/regrow.
• A secondary system tracks when & if an anchor becomes (un)available (e.g. when a nameplate frame (de)spawns), and will suppress or activate those containers when appropriate
  • note, I never actually implemented this part before crashing into a pit of unmotivation i've since been unable to climb out of

some considerations to deal with:

• this doesn't map all that well to how existing dynamic groups handle diverse anchor points (at least, when the author wrote a custom function to do so). So, if we really wanted to remain compatible, this would require a situation similar to BT2.
• tracking the availability of a particular anchor might be taxing in its own right, though I think we outsource a lot of that to LibGetFrame?

In such a container approach, having the anchor point (TOP, CENTER, BOTTOMRIGHT, etc) be part of the container identifier might also be valuable. For example, a user could wish to create a dynamic group which tracked specific buffs and debuffs in an encounter, and anchors the buffs to TOPLEFT (growing right), while debuffs are anchored to BOTTOMLEFT (also growing right).