questions about anchorChildren

[mark_steelman]

I’ve read the documentation but I still have some questions about this.

If I understand it correctly, the main thing this flag does is change the position of the objects in a displayGroup from coordinate based to a fraction.  It also allows the group to be rotated around it’s anchor point instead of it’s origin.

So, first, do I have that part right?

Second, how does it behave if there are groups inside of groups?

In my program, there is a player displayGroup, inside of a room displayGroup, inside of a map displayGroup.  I want to rotate the map around the player so that the player does not appear to move.  Something about the conversion to the new graphics 2.0 broke this functionality and I can’t figure out what.

[ingemar]

 If I understand it correctly, the main thing this flag does is change the position of the objects in a displayGroup from coordinate based to a fraction.

Not really. The problem I have is with the name anchorChildren. It might be just me, but my brain doesn’t process the term since it doesn’t modify the behavior of the children per se.

Regardless of if anchorChildren is true or false, adding objects to the group will still use the children’s common anchor point to position them relative to each other.

The only time anchorChildren comes into play is when you want to position the group on the stage.
When anchorChildren=true, the group will get its own anchor point which you can set like on any other object. This makes it easier to position if you have groups where the children’s common anchor point is at an arbitrary position.
When anchorChildren=false, the group’s positioning will be using the children’s common anchor point which may prove to be tricky to position the way you want.

To me the term anchorGroup =true makes more sense than anchorChildren =true as the ultimate effect of setting this property affects the group’s positioning, not the children within the group.

[mark_steelman]

I guess I’m not clear about what anchorChildren can do for me.  I can tell it is doing something because if I add objects to a group where anchorChildren = true then they are not in the same position as when I add them when it is false.  I examined the example of the clock hands spinning but that is a very limited use of a group… one object, a fixed group width…

Also, is anchorChildren the kind of thing I can turn on, then do some functions, then turn off?  It is very obtuse at this time.  I feel it needs to be explained a lot better than it has been explained before it is much use.

[rob]

@mark_steelman, have you read our tutorial/blog post on Anchor Points?  http://www.coronalabs.com/blog/2013/10/15/tutorial-anchor-points-in-graphics-2-0/

We try to explain the behavior there.

Rob

[mark_steelman]

I have read it and I played around with it.  I appreciate you writing it but it is not answering the questions I posted above.  I spent a little more time with it just now and changed the blocks so that they always appeared in the same location so I could be certain I wasn’t wasting your time.

AnchorChildren seems to simply move the reference point of the group to a point within the objects of the group defined by anchorX and anchorY.

I feel that what makes it confusing is the name. The children in a group are in a fixed position from the moment you add them to the group, they aren’t being anchored by anchorChildren. It would seem that it would make more sense if it were named, anchorAsRef = true or something like that. The way it is named, I was expecting the objects in my group to start sliding around when I moved the group and that is not what happens (thank God for that).

I think the problem I am still having is, there doesn’t seem to be any tools that allow you to quickly assertain the total width of all the objects in the group that are considered by anchorChildren.  You say that anchorChildren converts the group so that it has a finite width and height but I don’t have access to the information about those boundaries.

For example, referring to your tutorial, say I wanted to create 5 buttons that move the anchor point to the center of each of your 5 rectangles.  I think what I would have to do is determine which of the rectangles is farthest to the left and the right, then calculate the x offset and y offset of the target rectangle from that position, then move the anchorX and anchorY to the fraction equivalent of that position, then anchorChildren, then rotate.

That’s a pretty big mathematical mess, especially if you change which rectangle is in the center after they start rotating.

I am also still unclear on whether or not anchorX and anchorY has an effect on the behavior of a group when you don’t turn on anchorChildren. It doesn’t seem to affect the rectangles in your example until I anchorChildren. I might be trying to get it to do something that it just doesn’t do.  What I really want is to get back the functionality that existed before the change so that the code that I have been developing for almost a year will stop being broken by “graphics 2.0”. I want a coordinate based displayGroup with it’s reference point in the upper left corner. Now it seems that the only way I can get an upper left corner reference is by using fraction based positioning which is not nearly as flexible/simple.

[mark_steelman]

Ok, I worked it out.

In fact, anchorX and anchorY don’t do anything unless anchorChildren is active.  It seems that making anchorChildren exposed is kind of useless and causes needless confusion.  It would make the whole thing simpler to just have setting anchorX or anchorY to anything other than .5 automatically turn on the functionality and setting them both back to .5, .5 would turn it off.

The problem I was experiencing was actually related to the change in reference points and once I could sort that out I fixed it.  This other business turned out to be just confusion about what was causing the problem.

[rob]

I’m not sure how well this will help illustrate this from the way I understand it.  But lets start with groups:

In this example we have a display.newGroup() which by default has its origin at 0,0.  Positive coordinates of objects on the screen are in the white area.  Without using anchor children, if I move the group’s origin to say 100, 100 then every thing shifts down and to the right by 100 pixels.   This is what we are used to.  Now if you rotate the group, the blocks in this case would orbit the group’s new origin.  

Now add anchorChildren = true:

In this case, the group will have a constrained width and height and it’s X, Y by default now are centered in that imaginary box.  Since it’s a box it can now have anchor points, which groups don’t have (since they by definition don’t have a left, right, top or bottom edge).    Now if you move it by it’s X, Y, its the center of the faux-block.  If you rotate it, it’s going to rotate around the anchor point of the box.

You can determine the bounding box of a group (and what an anchored group becomes) using object.contentBounds (http://docs.coronalabs.com/api/type/DisplayObject/contentBounds.html)

Not two answer your original questions the best that I can:

1.  You have this partially right.  The group gets bounds and therefore has a center that can be rotated around and moved relative to that center point.  It’s the same as drawing things at negative locations relative to the group’s origin then moving the group’s X, Y.  By  letting you have boundaries, you can now have anchor points if you don’t want to use the center of the group (the X, Y) above.

2. Groups inside of Groups, I don’t know.  Let me see if I can get an engineer to discuss this further.

Rob

[Tom]

The anchorChildren property was never intended to be used with groups. It was added afterwards as a way to bring back some Graphics 1.0 compatibility where you can set a reference point for groups. Normally groups are dynamic and the bounding box is determined by the children within the group so there is no concept of Left, Right, Bottom or Top. By default, there are no anchor points for groups. Setting anchorChildren true enables anchor points for the group. Setting this property on groups within groups can be confusing and not recommended. In fact you shouldn’t be setting anchorChildren true on groups unless it’s the only way to achieve what you want.

The real purpose of the anchorChildren property is to determine what happens when you change the anchor point of a normal display object (e.g., non-group). By default, moving an anchor point shifts the object’s position. By setting anchorChildren to true, the object position will not move when the anchor point is changed. This mimics the behavior or changing the setReferencePoint in Graphics 1.0.

Containers are really groups with a mask and therefore have a bounding box. anchorChildren is set to true by default (for containers only).

[ingemar]

 If I understand it correctly, the main thing this flag does is change the position of the objects in a displayGroup from coordinate based to a fraction.

Not really. The problem I have is with the name anchorChildren. It might be just me, but my brain doesn’t process the term since it doesn’t modify the behavior of the children per se.

Regardless of if anchorChildren is true or false, adding objects to the group will still use the children’s common anchor point to position them relative to each other.

The only time anchorChildren comes into play is when you want to position the group on the stage.
When anchorChildren=true, the group will get its own anchor point which you can set like on any other object. This makes it easier to position if you have groups where the children’s common anchor point is at an arbitrary position.
When anchorChildren=false, the group’s positioning will be using the children’s common anchor point which may prove to be tricky to position the way you want.

To me the term anchorGroup =true makes more sense than anchorChildren =true as the ultimate effect of setting this property affects the group’s positioning, not the children within the group.

[mark_steelman]

I guess I’m not clear about what anchorChildren can do for me.  I can tell it is doing something because if I add objects to a group where anchorChildren = true then they are not in the same position as when I add them when it is false.  I examined the example of the clock hands spinning but that is a very limited use of a group… one object, a fixed group width…

Also, is anchorChildren the kind of thing I can turn on, then do some functions, then turn off?  It is very obtuse at this time.  I feel it needs to be explained a lot better than it has been explained before it is much use.

[rob]

@mark_steelman, have you read our tutorial/blog post on Anchor Points?  http://www.coronalabs.com/blog/2013/10/15/tutorial-anchor-points-in-graphics-2-0/

We try to explain the behavior there.

Rob

[mark_steelman]

I have read it and I played around with it.  I appreciate you writing it but it is not answering the questions I posted above.  I spent a little more time with it just now and changed the blocks so that they always appeared in the same location so I could be certain I wasn’t wasting your time.

AnchorChildren seems to simply move the reference point of the group to a point within the objects of the group defined by anchorX and anchorY.

I feel that what makes it confusing is the name. The children in a group are in a fixed position from the moment you add them to the group, they aren’t being anchored by anchorChildren. It would seem that it would make more sense if it were named, anchorAsRef = true or something like that. The way it is named, I was expecting the objects in my group to start sliding around when I moved the group and that is not what happens (thank God for that).

I think the problem I am still having is, there doesn’t seem to be any tools that allow you to quickly assertain the total width of all the objects in the group that are considered by anchorChildren.  You say that anchorChildren converts the group so that it has a finite width and height but I don’t have access to the information about those boundaries.

For example, referring to your tutorial, say I wanted to create 5 buttons that move the anchor point to the center of each of your 5 rectangles.  I think what I would have to do is determine which of the rectangles is farthest to the left and the right, then calculate the x offset and y offset of the target rectangle from that position, then move the anchorX and anchorY to the fraction equivalent of that position, then anchorChildren, then rotate.

That’s a pretty big mathematical mess, especially if you change which rectangle is in the center after they start rotating.

I am also still unclear on whether or not anchorX and anchorY has an effect on the behavior of a group when you don’t turn on anchorChildren. It doesn’t seem to affect the rectangles in your example until I anchorChildren. I might be trying to get it to do something that it just doesn’t do.  What I really want is to get back the functionality that existed before the change so that the code that I have been developing for almost a year will stop being broken by “graphics 2.0”. I want a coordinate based displayGroup with it’s reference point in the upper left corner. Now it seems that the only way I can get an upper left corner reference is by using fraction based positioning which is not nearly as flexible/simple.

[mark_steelman]

Ok, I worked it out.

In fact, anchorX and anchorY don’t do anything unless anchorChildren is active.  It seems that making anchorChildren exposed is kind of useless and causes needless confusion.  It would make the whole thing simpler to just have setting anchorX or anchorY to anything other than .5 automatically turn on the functionality and setting them both back to .5, .5 would turn it off.

The problem I was experiencing was actually related to the change in reference points and once I could sort that out I fixed it.  This other business turned out to be just confusion about what was causing the problem.

[rob]

I’m not sure how well this will help illustrate this from the way I understand it.  But lets start with groups:

In this example we have a display.newGroup() which by default has its origin at 0,0.  Positive coordinates of objects on the screen are in the white area.  Without using anchor children, if I move the group’s origin to say 100, 100 then every thing shifts down and to the right by 100 pixels.   This is what we are used to.  Now if you rotate the group, the blocks in this case would orbit the group’s new origin.  

Now add anchorChildren = true:

In this case, the group will have a constrained width and height and it’s X, Y by default now are centered in that imaginary box.  Since it’s a box it can now have anchor points, which groups don’t have (since they by definition don’t have a left, right, top or bottom edge).    Now if you move it by it’s X, Y, its the center of the faux-block.  If you rotate it, it’s going to rotate around the anchor point of the box.

You can determine the bounding box of a group (and what an anchored group becomes) using object.contentBounds (http://docs.coronalabs.com/api/type/DisplayObject/contentBounds.html)

Not two answer your original questions the best that I can:

1.  You have this partially right.  The group gets bounds and therefore has a center that can be rotated around and moved relative to that center point.  It’s the same as drawing things at negative locations relative to the group’s origin then moving the group’s X, Y.  By  letting you have boundaries, you can now have anchor points if you don’t want to use the center of the group (the X, Y) above.

2. Groups inside of Groups, I don’t know.  Let me see if I can get an engineer to discuss this further.

Rob

[Tom]

The anchorChildren property was never intended to be used with groups. It was added afterwards as a way to bring back some Graphics 1.0 compatibility where you can set a reference point for groups. Normally groups are dynamic and the bounding box is determined by the children within the group so there is no concept of Left, Right, Bottom or Top. By default, there are no anchor points for groups. Setting anchorChildren true enables anchor points for the group. Setting this property on groups within groups can be confusing and not recommended. In fact you shouldn’t be setting anchorChildren true on groups unless it’s the only way to achieve what you want.

The real purpose of the anchorChildren property is to determine what happens when you change the anchor point of a normal display object (e.g., non-group). By default, moving an anchor point shifts the object’s position. By setting anchorChildren to true, the object position will not move when the anchor point is changed. This mimics the behavior or changing the setReferencePoint in Graphics 1.0.

Containers are really groups with a mask and therefore have a bounding box. anchorChildren is set to true by default (for containers only).

[kilopop]

Tom, we are using nested groups extensively in G1.0 with fantastic applications especially to create a kind of parented animation. Think of wheel group rotating, car body group moving up and down, all children of one car group which is moving across the screen. Are you saying this is no longer possible in G2.0? Why can’t anchorChildren be true for groups within groups?

[Tom]

I never said you can’t set anchorChildren on groups within groups, but don’t expect it to work the same way as Graphics 1.0 and nested groups.

[kilopop]

No, anchors don’t work the same as reference points that’s for sure. But once anchors are being used as designed there’s no reason they shouldn’t work theoretically. Are you talking about unpredictability of performance by G2 when it comes to nested anchors, in other words, bugs? It is exasperating that group anchors/reference points have de-evolve in G2 that they require so much more effort and code to achieve something done so effortlessly in G1.

[bjsorrentino]

Hi @kilopop,

Have you read our guide on groups and anchorChildren? This is the most clear guide available (or at least I haven’t seen anything more descriptive). It should illustrate exactly what is happening when you use anchorChildren on groups.

http://docs.coronalabs.com/guide/graphics/group.html

Take care,

Brent

[kilopop]

Thanks Brent, I understand how they work. Clearly they work differently to reference points. But the point I’m asking is whether there’s something we haven’t been told yet about the stability of anchor points, as hinted by Tom posting stuff like:

“Setting anchorChildren true enables anchor points for the group. Setting
this property on groups within groups can be confusing and not
recommended. In fact you shouldn’t be setting anchorChildren true on
groups unless it’s the only way to achieve what you want.”

There was never a problem with reference points when it came to nested groups - you could nest til your heart was content. Now it’s clearly become more difficult to do. So my questions would be:

Is Tom saying it is still possible and robust to nest groups in G2 if not a lot more complicated than it used to be in G1? Or is he saying nested groups are not encouraged because goodness knows if G2 can actually handle it i.e. possible instability of the api?