Component invalidaton lifecycle

[jasonsturges]

A display object's `render()` method will call every frame, right?

Is there a component lifecycle for validation built in to Pixi, akin to fl.controls usage of fl.core.UIComponent?

As in, a way to trigger rendering / update only when needed per display object (not the entire Pixi application) when multiple properties are set on the same frame.

For example, if I have several properties that determine state of a display object, should I calculate that in `render()`; or, should I set an invalidate flag to be handled on the next frame?

Pseudo-code example:

class MySprite extends PIXI.Sprite {
  set color(value) {
    // ...
    this.dirty = true;
  }

  set selected(value) {
    // ...
    this.dirty = true;
  }

  render(renderer) {
    super.render(renderer);

    // Calculate display state here?
    // Is there a better lifecycle hook?
    // Or, manually validate using the animation frame?
    this.validate();
  }

  validate() {
    // Validate presentation state if dirty
    if (this.dirty === false)
      return;
    
    this.dirty = false;

    // ...calculate state based on properties
    // if color is red and selected is true, texture = red-selected.png
  }
}

 

Edited December 8, 2019 by jasonsturges

[ivan.popelyshev]

Only partial.

PixiJS cares about transforms of all elements, calculated vertices for sprite, graphics bounds, some other things.

https://github.com/pixijs/pixi.js/blob/dev/packages/math/src/Transform.ts#L235

https://github.com/pixijs/pixi.js/blob/dev/packages/sprite/src/Sprite.js#L237

https://github.com/pixijs/pixi.js/blob/dev/packages/graphics/src/GraphicsGeometry.js#L194

https://github.com/pixijs/pixi.js/blob/dev/packages/display/src/DisplayObject.js#L266

We switched from simple dirtyflags to dirtyID's because usually one object is watched by several validators. The trick is also to set watcher updateID to -1 if parent was changed.

Unfortunately we cant cover everything:

If we implement dynamic props like in react and angular, it will seriously affect debuggability of code.

I have my own Stage to execute flash SWF's, I forked it from mozilla shumway, fixed many things and covered them with tests, spent 2 years on it, and I still think it doesn't fit vanilla pixijs. I made it to cache results of filters, because they are too heavy: blurs, shadows, glows, e.t.c.

If you want full control like that - I advice to copy code of pixi/display , sprite, graphics and whatever elements you need, to make your own scene tree. It is possible, I proved that. Most of our logic is already in inner components : Transform, Texture, GraphicsGeometry, e.t.c.

Its even possible to make FilterSystem and MaskSystem work with your components, just need some extra interfaces like MaskTarget or FilterTarget.

What I don't recommend - is to try track dirtyRects. Its hell, don't even try it. Stick to elements that you cache in renderTextures.

Btw, that's the reason I want to make `cacheAsBitmap` not a boolean ,but a number. Just `cacheAsBitmap++` should invalidate the cache.

 

 

Edited December 9, 2019 by ivan.popelyshev

[ivan.popelyshev]

Another possibility is removal of updateTransform FOR's - but you need special event queue per root stage element, and every element should add itself to it in case of change. I've spent big number of hours to debug that, and now my work project can handle 6000+ animated objects and it spends time on them only when animation is switched to another, element moves, or camera moves far away from clipping rectangle.

Edited December 9, 2019 by ivan.popelyshev

[jasonsturges]

@ivan.popelyshev This makes a lot of sense.  Really appreciate the insight here.

Need to digest this, and might have some follow up questions.

Similar situation with a complex data visualization involving a few thousand sprites.  Pixi.js performance is blistering fast, solid at 60fps, but I have some reservations about patterns I'm implementing.

Thanks again for all the insight and support!