PIXIv5 and consumable components

[pongstylin]

So I'm refactoring my game to use PIXI v5 consumable components so that, with webpack tree shaking, the JS bundle never sees modules that I don't use and omits exports from modules that I do.  Unfortunately, despite being comfortable with the PIXI documentation and looking through PIXI source code, it is proving difficult to navigate the plugins that I need to make basic things work.  I've included a work-in-progress code snippet below where I pull in the various PIXI bits that I need.  My immediate problem is that the Canvas Renderer fails to render the stage.  The stage is a "Container" object.  It crashes when it attempts to call the "renderCanvas" method on the Container object here.  The method doesn't exist.  So, I'm guessing I need to import something and/or register another or different plugin.

So here's a summary with my feedback/questions:

1. Is there a list of all of the @pixi modules somewhere with their exports?  I've tried to look at the normal PIXI documentation, but each class doesn't seem to call out the @pixi module that contains it.  So, a list would help me figure out the right module to import.
2. How do I get past the canvas rendering issue I'm experiencing?
3. Notice my comment in the code snippet below.  Is it really necessary to create canvas objects at the point when a module is imported?  Perhaps move some of that logic to a constructor?

import { Renderer, BatchRenderer, BaseTexture, Texture } from '@pixi/core';
import { CanvasRenderer } from '@pixi/canvas-renderer';
import { InteractionManager } from '@pixi/interaction';
import { Container } from '@pixi/display';
import { Sprite } from '@pixi/sprite';
import { Graphics } from '@pixi/graphics';
import { Text } from '@pixi/text';
import { Rectangle, Polygon, Point } from '@pixi/math';

Renderer.registerPlugin('batch', BatchRenderer);
Renderer.registerPlugin('interaction', InteractionManager);
CanvasRenderer.registerPlugin('batch', BatchRenderer);
CanvasRenderer.registerPlugin('interaction', InteractionManager);

/*
 * Some game classes are shared between the client and server.  Some of them have
 * rendering methods that are only called on the client side, which use PIXI classes.
 * But, the PIXI classes can not be statically imported since PIXI requires the 'document'
 * object to load modules successfully.  So, provide a global access point which would
 * exist in the client context, but not server context.
 */
window.PIXI = {
  CanvasRenderer,
  BaseTexture,
  Texture,
  Container,
  Sprite,
  Graphics,
  Text,
  Rectangle,
  Polygon,
  Point,
};

 

Edited February 15, 2020 by pongstylin

[ivan.popelyshev]

> Unfortunately, despite being comfortable with the PIXI documentation and looking through PIXI source code, it is proving difficult to navigate the plugins that I need to make basic things work.

I think you are tired. Your code looks good enough and you are really close to your target. Maybe if you ask a few questions like the one about renderCanvas - it'll be fine  

Praise @Mat Groves that pixi is just a lib and not a framework.

> It crashes when it attempts to call the "renderCanvas" method on the Container object here. 

Container is in display, canvas part is in canvas-display.

> Is it really necessary to create canvas objects at the point when a module is imported?  Perhaps move some of that logic to a constructor?

Running pixi in server environment is not considered a priority for us, there are many other pressing matters that affect architecture.

Use "node-canvas" or any other thing that makes shim.. and now I remember that thing: https://github.com/Prozi/pixi-shim

In case you fork pixi and change those document-related parts,  track which changes you make , to upgrade your pixi version later.

I made many big changes in pixi forks,. for example full typescript fork 2.5 years ago. We are finally moving main repo to TS now. Part of your problem - tree shaking - existed for a long time, but https://pixijs.io/customize/ is only year old or so. Same way, making pixi server-friendly will really take time not because of amount of code but because its not a priority and this feature cannot in any way obstruct our code. Just imagine it from maintainer point of view: we will have to reject PR's without lazy initialization, that's a serious change in review process!

Edited February 15, 2020 by ivan.popelyshev

[pongstylin]

Yes indeed.  I've never seen a web framework that I've liked.  But this library and web component libraries have pleased me very much.  Moving to the consumable model is just the next level of awesome.

I see the canvas-display module doesn't have exports and decorates the existing Container class, so added "import '@pixi/canvas-display'" to my code and it works just fine.  But my documentation question went unanswered.  Is there a list of such components someplace?  Just seeing a list would allow me to intuitively find what I need such as in this case.  Tired or not, I'm not sure how I could've figured this out.

Not actually trying to run PIXI in a server environment.  It's just the fact that my modules can't statically import PIXI modules without crashing.  The imported modules would go unused in a server context, but used in a client context.  It is an unusual case where my modules are used in both a server (NodeJS) and client context.  On the server the modules serve as a state engine (e.g. move piece on this square to another square, if allowed).  On the client, it also serves as a "local" state engine, but calls rendering methods to make the domain concepts visible (e.g. display the piece on this square).  The game board and game pieces are two kinds of classes that are shared between the client and server and make use of PIXI classes only when their rendering methods are called.  So, while I understand that I can't use PIXI in a server context, it is just unusual that simply importing them causes the server to blow up.  If moving the logic to constructors or at least skipping logic based on "document" existence checking is not a priority, then that's fine.  It's just a nice-to-have.  Perhaps something to consider as architecture changes are made for other reasons.

A new question.  So, this "BatchRender" plugin, if omitted, does crash when using the WebGL renderer.  It seems to crash for expected reasons - it assumes that a a batch plugin is defined.  But when I add the plugin to the CanvasRenderer, it crashes at the point I instantiate the renderer.  Perhaps there is no point in using the BatchRenderer in a canvas context since there is no GPU to which textures need to be uploaded.  Is there documentation anyplace that lists the various renderer plugins developed by the PIXI team and when I would or wouldn't use a particular plugin?

[pongstylin]

And since my canvas renderer was silently failing to render anything, I intuitively figured out 3 more modules I needed.  I looked at "canvas-display" and was like hmmmm, maybe I can swap out "display" with "sprite", "graphics", and "text" to make those things show up.  Bingo, yay for pattern recognition.  But running on intuition isn't very satisfying.  There's got to be a guide on this right?

[ivan.popelyshev]

> Is there a list of such components someplace

You are the first one who requests this list.

> Is there documentation anyplace that lists the various renderer plugins developed by the PIXI team and when I would or wouldn't use a particular plugin?

Again, you are the first one Maybe after full TS conversion, maybe when there will be at least 5 or so people like you who experiment with different bundles of pixi - we will have those lists as a part of documentation.

===============

> So, this "BatchRender" plugin, if omitted, does crash when using the WebGL renderer.

> Perhaps there is no point in using the BatchRenderer in a canvas context since there is no GPU to which textures need to be uploaded.

BatchRenderer made for WebGL. I dont know why do you register it for canvas when canvas has one of its own.

https://github.com/pixijs/pixi.js/blob/dev/bundles/pixi.js-legacy/src/index.js#L19

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

CanvasRenderer mirrors the old architecture of pixi v3-v4, it doesnt have systems, its not compatible with any of webgl systems/plugins.

Only Accessability and InteractionManager can be canvas/webgl renderer plugins.

===============

PixiJS wasn't planned on UML diagram. All those things were made without big planning. We are going step-by-step, maybe in a few months our architecture will be in place you somehow imagined it supposed to be, but right now it is not.

> But running on intuition isn't very satisfying.  There's got to be a guide on this right?

All this modularity was achieved naturally. 7 years evolution of library, all those years we were growing community - and here you are , the first one who wants to use modularity by using intuition and not knowing all the code. It was not possible before.

Edited February 17, 2020 by ivan.popelyshev