Pixi.js: Do Sprites need children?

[GoodBoyDigital]

Does anyone use the PIXI.Sprite's children functionality?
What are cases when you need it instead of just 2 sprites in a container?

If we remove this for v3 then we can optimize various sprite functions to be a little faster and cleaner. The same goes for graphics too.

Keen to get some opinions from you guys n gals on this one!

Cheers!

Mat

[goldenratio]

no, I never used it for PIXI.Sprite.
But I use it for PIXI.DisplayObjectContainer (example: remove all children)

[englercj]

To be clear, this is about making Sprite inherit from DisplayObject instead of from DisplayObjectContainer so that it cannot have children. This will be a change to Sprite and Graphics, nothing else would be affected.

[mattdesl]

I've used this before. My use case was a Sprite that uses a 2x2 white opaque part of a texture atlas, so that I can render rectangles and lines without any shader/buffer/texture switches and take advantage of the sprite batcher. That acted as the opaque background of a widget, and I added children to the sprite.

I'd be curious about the optimizations that could be made. To what extent do they fall into a "premature" category?

[amadeus]

I'll re-iterate my thoughts from Twitter, just to have them logged here:

It would be really useful if say you had a space ship and you wanted blinking lights on it. You might also have physics set on the ship, and not be abstracted away from the ship to a DisplayObjectContainer.

I guess what I am trying to say is that I like the mental/model construct of interacting directly with a Sprite, whether or not they have children Sprites.

It's not a huge deal, but I guess if I had my ideal construct, I wouldn't want to have to 'special case' sprites that also contain children sprites.

[serprex]

I wouldn't be opposed to this change, but I abuse this extensively

https://github.com/serprex/openEtG/blob/master/views/Match.js#L241
https://github.com/serprex/openEtG/blob/master/gfx.js#L118
https://github.com/serprex/openEtG/blob/master/views/Shop.js#L89

[JiDW]

I sometime use children of sprites. For example, when I need to create a button, to add the text inside. I do this without a solid reason, because I imitate the behavior of DOM and sometime find it easier to set the position of the children relative to its parent. TBH, when I started to learn PIXI, I had no idea if an event could be fired if a non-interactive sprite was over my interactive sprite. That's why I started to do this.

[NikkiKoole]

I've used the functionality (in Graphics too) but mostly because of laziness and hackfestmood. I am for the change of extending only from DO instead, It would lead to a situation were all use cases I can think of can only be done in one way which is good imo, @mattdesl case/question is also good though.

[beeglebug]

I think its useful when you want to do inherited rotation, for something like an arm for example, with an upper arm, lower arm and hand parented together. If you had to use containers it would involve 6 objects instead of 3.

[amadeus]

I think @beeglebug has hit on something pretty important in terms of usability.

@GoodBoyDigital what kind of performance optimizations are we talking about? Would they have overall real world impact? Perhaps there's a good reason to have a sort of optimized Sprite that can't have children, and still preserve the existing Sprite behavior. Similar to SpriteBatch vs DisplayObjectContainer

[kittykatattack]

One enthusiastic vote for sprites with children. :+1:
It's a sensible and simple API model for an end-user like me to work with.
I would gladly sacrifice a bit of performance for that convenience.

[samreid]

My project is currently investigating using Pixi as a renderer (more details in https://github.com/phetsims/scenery/issues/350). The complexity of our implementation would be considerably higher if Pixi nodes (including Graphics, Sprite and Text) couldn't have children. But it would also be good to quantify the performance tradeoffs.

Just brainstorming here: one way to get improved performance where possible without complicating the API would be to have Pixi internally switch between the DisplayObject style and DisplayObjectContainer style when the first child is added. Or perhaps this would just increase Pixi's complexity too much and also the application startup time :(

[alamboley]

Do Sprites need children? Absolutely!!

But think in an other way... Sprites are the only way to display a simple texture and they can have children. Why there isn't an Image class extending DisplayObject?

It would be really convenient since in a first time most people would use Image object instead of Sprite. And then we could see if we mostly use a DisplayObjectContainer and push Image inside. Or just a Sprite with many others Sprite children.

[YopSolo]

Sure they need children :)
And Pixi maybe need an additionnal DisplayObject like a Bitmap Class ( just like flash API :) )

[andrewstart]

I have never added children to Sprite or MovieClip in any project I have worked on.

[brianblakely]

I may have added children to Sprites in the past, but I don't recall that ever being a primary use-case.

If that suddenly broke, I would just switch to DOCs full of Sprites.

[shanemccartney]

Yeh initially I thought this was odd its not what I expected, but it is handy as many of the comments above especially when you want the image on the background and other elements on top such as a button with a TextField for less interesting example!! Initially I did this always with DisplayObjectContainers but once I realised Sprite could do this then I thought I would use this instead when I wanted this type of functionality.

I suggest create a new class for this i.e. Image or Bitmap. Thats what starling does for AIR otherwise yeah I imagine for v3 update will require many projects needed to refactor code in these cases.

[jppresents]

I am using pixi through phaser. And I love that I can attach sprites to other sprites.

I mean, how else would I build a tank with a rotation turret and animated trails?

(Example here: http://jppresents.net/games/tanks/ - this is using phaser 2.x and pixi through that).

The example tank is a sprite with the turret and the trails as children sprites.
(With offsets and in case of the turret with it's own rotation).

Everything transforms (moves, rotates) together with the main sprite (the tank body), without any additional code.
How would this work without children?

[alexh00]

Coming from a Starling & Adobe Air background I initially thought 'Sprites with children? Yuk!'
But then on occasion I found I needed another additional sprite where I had initially put just one and ended up using the feature out of pure laziness, rather than laboriously swapping the first sprite for a DisplayObjectContainer and so on. So that is the only benefit I can see - providing a lazy option for lazy people. I am sure it would be somehow cleaner to extend DisplayObject instead though. I can't see any scenarios in which having children of a Sprite could achieve any benefits that couldn't also be achieved more or less equally simply through using DisplayObjectContainers, even if it does mean having one or two more display objects over all.

[photonstorm]

For what it's worth I've never used a child of a Sprite either, in any Pixi/Phaser project. I used to do it a lot in Flash though, where it just felt more natural.

Having said that I know a significant number of devs who do use this feature in their games. Part of me thinks if you're going to claim you support a true display list, then you need to actually support a true display list! Yet DOCs can do everything Sprite children can, they're just a bit more verbose in setting them up - they require more objects, and thus more memory, to achieve the exact same thing you can do currently.

If this is all just about speeding-up batching then perhaps a non-container base object would make more sense? Like a Particle or Image class.

[GoodBoyDigital]

The people have spoken! :)
Sprites with children it is!

Thank you all for your feedback everyone!

[serprex]

I'd like to add to this:

If there's optimization potential for no-children DOCs, then perhaps detecting no-children DOCs dynamically is the route to go. If that works, why have both DisplayObject & DisplayObjectContainer? Why not have all DisplayObjects be capable of containing children?

[brianblakely]

+1 I was curious about this as well.

[agamemnus]

I don't see any performance plus or minus here. It seems to be an organization question for me.

If sprites could have children, you could extend your code easier.

But yes, a no-children sprite list would need to be easily accessible.

And then, what's the point of DisplayObjectContainers? Just make everything a sprite that may or may not have children or may or may not have a texture attached to it. (Is that too retro)?

[clark-stevenson]

My Phaser Terminology might be obscure, but for me, I never use Sprites. Basically if I need a DisplayObjectContainer, I use a Group. If its a DisplayObject, I use a Image. I know the relationships of what I am building in advance, and see no reason (other than confusion) why I would create a node that does both at the same time. I find it easier to just manage a display object container to build what I guess is a "Sprite".

[englercj]

In PIXI a sprite is just a textured object. Phaser.Group inherits from PIXI.DisplayObjectContainer. Phaser.Image inherits from PIXI.Sprite (which inherits from PIXI.DisplayObjectContainer) and displays a texture. Phaser.Sprite also inherits from PIXI.Sprite and displays a texture and includes physics and animations.

[dakom]

I realize this is a _really_ old issue - but I'm playing around with abstracting PIXI into a react-renderer and the performance hit is significant there. Not on the PIXI side, but on the React side.

My plan for now is to have two types of Sprite wrappers - those that can have children and those that can't, with the default Sprite being those that _can't_.

Is this something that already has a naming convention or split in v5? My intent is to name the containerized version "SpriteContainer".

Again this isn't touching any PIXI internals, and under the hood it's still Sprite in both cases - just wanted to make sure I'm not missing some pre-existing naming convention ;)

[ivanpopelyshev]

Its difficult to explain DisplayObject and Container difference, they're kinda the same thing just with separated functionality, it comes from flash.

And in flash, Sprite can have children too, its based on DisplayObjectContainer

How your experiments are going?

[dakom]

Experiments are going good so far... React is definitely a bottleneck but not a showstopper for most cases.

If I can get this change working (edges can't be containers), then react+pixi performs at around 20,000 bunnies where pixi native performs at around 50,000 bunnies. totally useable! but I need to introduce this change first...

[agamemnus]

Just wondering here but what's the use case? Can you give a link to your
work?

On Oct 4, 2017 12:32 AM, "David Komer" [e-mail] wrote:

Experiments are going good so far... React is definitely a bottleneck but
not a showstopper for most cases.

If I can get this change working (edges can't be containers), then
react+pixi performs at around 20,000 bunnies where pixi native performs at
around 50,000 bunnies. totally useable! but I need to introduce this change
first...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pixijs/pixi.js/issues/1380#issuecomment-334047182, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADFJWGJkslw1Nz1okGAM1BXMOm89XYVhks5sowpMgaJpZM4DW7sQ
.

[dakom]

@agamemnus - use case is to drive PIXI with React

I just finished some initial benchmarking stuff... writing a custom renderer did not help performance.

But it did help usability :)

Just submitted the topic on the PIXI forum with links to code and demo: http://www.html5gamedevs.com/topic/33240-react-fiber-renderer/

[lock[bot]]

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.