Modify Inheritance Graph of High-Level Objects

[bigtimebuddy]

Current

Right now, the inheritance chain of PixiJS looks like this. This is not exhaustive list, but focuses on the high-level API objects.

• DisplayObject
  • Container
    • ParticleContainer
    • Sprite
      • Text
    • Mesh
      • SimpleRope
      • SimplePlane
        • NineSlicePlane
    • BitmapText
    • Graphics

Proposed

• DisplayObject
  • Container
    • ParticleContainer
    • BitmapText
  • Sprite
    • Text
  • Mesh
    • SimpleRope
    • SimplePlane
      • NineSlicePlane
  • Graphics

Rationale

Sprite, Text, Graphics, etc are often abused as Containers. In reality, we do not want users adding children to these objects because of how rendering children interacts with the default render of the object and changes with bounds/dimensions (and also pivot and anchor).

Sprite for example: when children are added, you don't have control over when the default texture renders. Say you want the Texture to render after. It can get pretty mess quickly.

In reality, the PixiJS scene graph would benefit by having simpler leaf objects that are non-Containers. There would be less recursion for every object.

This is a significant change but one that would help create a more consistent and clear paved-path for developers.

[mreinstein]

This kind of problem will never go away, as long as pixi is based on the completely broken premise that is "simplified coding by embracing inheritance and OOP".

Seriously, I love pixi for what it does, but in the 6+ versions that have been built these class hierarchy bugs never go away, they just morph into something different but equally nonsensical.

This isn't a fault of pixi, it's a fault of architecting things based on a hierarchical object model.

Data oriented design should be the way forward. 🙏

[GoodBoyDigital]

Hey @bigtimebuddy , been thinking about this for the next version. Starting to lean into this idea a lot more! It would really simplify a tonne of logic and also give some room to optimise for performance - which i love!!

Essentially I think we get away with having three scene objects:

• DisplayObject (transform)
  • Container (has children)
  • Renderable (has a view - sprite view / mesh view / text view etc)

Not even married to the idea of them extending a display object, just need to figure out a nice way for them to share the transform functionality.

[bigtimebuddy]

Love that idea

[miltoncandelero]

Is that "Renderable" an interface only or does it have some shared methods? Say, Sprite extends Renderable or implements Renderable?
Or Rendrable is just a concept and we just have things extend the Display Object?