Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

swapChild implemented via addChildAt #350

Closed
wants to merge 5 commits into from

Conversation

@ccoenen
Copy link

commented Oct 11, 2013

swapChild was currently not available, i implemented it via two simple addChildAt calls. This would also close #287.

@ccoenen

This comment has been minimized.

Copy link
Author

commented Oct 11, 2013

I also have a different approach, re-knitting the linked list, but somehow i had an error somewhere halfway through that created an infinite loop. If you're interested in that, you can have a look at it right here: ccoenen@ef34c55

@englercj

This comment has been minimized.

Copy link
Member

commented Oct 11, 2013

I'd be interested to compare this with phaser's swap implementation:

https://github.com/photonstorm/phaser/blob/dev/src/core/Group.js#L232

@xixixao

This comment has been minimized.

Copy link

commented Oct 11, 2013

Hey guys, I am trying to figure out, what is the way to handle order of sprites in PIXI? My particular situation: I have 10000 sprites and say 100 others which I need to place in front of specific sprite from the big group. The only thing I can think of now is to keep track of indices of the 10000 sprites and use addChildAt. Is there a way to addChildAfter(sprite1, sprite2) - that would be all I need, I think.

@drkibitz

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2013

An insertBefore and an insertAfter would be useful, but if there are already internal references (linked list) then I don't believe building on those methods for implementing a fast swap is needed.

I guess my problem is that the linked list implementation is a bit confusing in regards to property names, and I have unfortunately tried to avoid it. I would love to have exposed properties such as firstChild, lastChild, previousSibling, nextSibling, and parent. I think the only one that exists like this is parent, while finding the rest of those will require a bit longer stint of reverse engineering. I remember reading in another thread that both a doubly linked list and a children stack are implemented for different reasons. From my point of view I would never use the stack to manipulate order if there is already a linked list. What is the benefit of the stack other than looping?

@englercj

This comment has been minimized.

Copy link
Member

commented Dec 8, 2013

Implemented #431

@englercj englercj closed this Dec 8, 2013

@englercj englercj referenced this pull request Dec 8, 2013

@ccoenen ccoenen deleted the ccoenen:swapChildReimplement branch Dec 8, 2013

@lock

This comment has been minimized.

Copy link

commented Feb 26, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 26, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.