I wish pixi.js could run on node-webgl

[vitalije]

I would like to use pixi.js not inside browser, but on WebGL canvas obtained through node-webgl library. I understand that pixi.js itself uses also Canvas2D context, and that it won't be possible to use all features of pixi.js without 2D canvas. Yet, I would like to use those functions that do not need to depend on 2D canvas. I have already made some experiments and found out that it is possible to render sprites on WebGL obtained through node-webgl. It seems however that WebGL context objects are not 100% compatible. I am willing to try to port pixi.js myself (at least those features that are used by RPGmaker MV) to use webgl context provided by node-webl module. However, I need some help. If somebody can point me to the right direction it would be really a big help. What pixi.js requires/uses from WebGL context? How to find what is missing from context obtained through node-webgl comparing Chrome's WebGL context? Maybe it would be possible to make a thin layer - adapter that would transform a context obtained through node-webgl to something that pixi.js expects.

Another library I have found is node-canvas that provides 2d context for drawing. It would be great if pixi.js could run on some combination of those two libraries.

[GoodBoyDigital]

Hi there! If there was some kind of feature comparison for the webGL vs node-webGL I could help and advise.

[vitalije]

I am not aware of such comparison. As I stated before I would like to know what pixi.js requires/expects from WebGL context (a minimal set of functions, properties). I tried to find the answer myself by reading pixi.js code but without much luck. I have found that in some cases node-webgl is more demanding on type checking arguments used to call some of its functions than a normal browser context. It could be tweaked to accept arguments from pixi.js.

Anyway I didn't achieve much 😞. If you @GoodBoyDigital or anyone else have some advice I would appreciate it very much.

[englercj]

I assume it is the DOM features that make pixi unable to run on just node-webgl?

[vitalije]

Yes, that is one part of the problem. OTOH I could live without certain functionalities of pixi.js that rely on DOM. IIRC functions for displaying styled text depend on DOM. Maybe some others too.

The problem is that even if client application never calls any of those functions, pixi.js still refuses to run functions that don't depend on DOM.

[GoodBoyDigital]

any luck on this?

[vitalije]

not really 😞

[englercj]

Hopefully in v5 we can split the codebase enough to where pixi can run on node-webgl. But, keep in mind this is not one of our target platforms. We will do what we can going forward.

[okcoker]

I want to make an issue similar to this but since @vitalije mentioned node-canvas I suppose I'll add comments here.

I'm looking to use Pixi.js but for my project, I would also need node support. I'm currently using node-canvas and in seeing past issues like #1277, it seems we currently need some sort of shim to get things working. I'm currently using the following:

// pixi-shim.js
global.document = require('jsdom').jsdom();
global.window = document.defaultView;
global.window.document = global.document;

global.Canvas = require('canvas');
global.Image = require('canvas').Image;

// Node canvas Image's dont currently have `addEventListener` so we fake it for now.
// We can always make updates to the node-canvas lib
global.Image.prototype.addEventListener = function(event, fn) {
    const img = this;

    switch (event) {
        case 'error':
            img.onerror = function() {
                img.onerror = null;
                img.onload = null;
                fn.call(img);
            };
            break;

        case 'load':
            img.onload = function() {
                img.onerror = null;
                img.onload = null;
                fn.call(img);
            };
            break;
    }
};

global.Image.prototype.removeEventListener = function() {};
global.navigator = { userAgent: 'node.js' }; // could be anything

Now, this just allows me to at least require the lib in a node environment. I fully realize having this shim in the first place is a bit hacky, but since I'm pretty set on getting this working, it's a start. Also I should mention I don't have much webgl experience (that's why I'm planning to use this lib in the first place) so I can't speak on how node-webgl or headless-gl will work with this (Not even sure about the difference). I do have a few questions though:

As far as using this lib in a node environment, would there be a difference in getting Pixi.js working with node-canvas or a node-webgl library? Do you think the performance of the webgl variant would still be faster?

I personally would be working on getting this working specifically with node-canvas but I was curious if I should be going off of version 4, or just fork the dev branch?

[englercj]

As far as using this lib in a node environment, would there be a difference in getting Pixi.js working with node-canvas or a node-webgl library?

Probably, but not sure what.

Do you think the performance of the webgl variant would still be faster?

Depends on the implementation of node-canvas, node-webgl, the platform you are running on, the gfx drivers, the card hardware, etc.

I personally would be working on getting this working specifically with node-canvas but I was curious if I should be going off of version 4, or just fork the dev branch?

Completely up to you, like I mentioned before we may merge some unobtrusive changes but a rework so that it can run on node is not in the cards. Server-side rendering is not a goal of this library.

[gre]

I was looking for using pixi.js in a non-browser context as well, and unfortunately the library is far from ready for this from a few investigation in the source code. It relies on navigator to detect for mobile (and crash if not), it relies on window to be defined at multiple places, it also requires on document.createElement("canvas") for things like creating a white texture (which could technically be done with texImage2D and a UInt8Array btw).

so these point are stopper for me, for now, if you guys consider it's important to fix that, I can give more time on trying to fix them all but if you think pixi.js should stay for browser i'm ok as well.

I just wanted to use PIXI.js as an example for react-native-webgl (webgl implementation for react-native) – BTW regl and Three.js both works ok because you can nicely give a WebGLContext to them and they don't rely a lot on window, document or navigator. (even tho the harder topic is support of Texture, because usually needs to have Image, however hopefully they also support to give a raw WebGLTexture (with more or less hidden ways) )

It can be good to identify and fixes such external dependency, not just for supporting more usecase than browser but also to improve the general code I think (like externalizing implicit dependency is I believe a general good practice in libraries)

Best regards,
gre

[Prozi]

based on what @okcoker wrote I created https://www.npmjs.com/package/pixi-shim

use at your own risk ;) ;)

[timknip]

@Prozi @okcoker Here's another one ;-) Seems to work ok with PIXI 4.7

• https://github.com/timknip/node-pixi
• https://www.npmjs.com/package/node-pixi

Uses node-canvas for images.

Largely untested so use at your own risk.

[Prozi]

updated pixi-shim

now

• at all required stages stuff is included (like jsdom, canvas lib etc) only if it isnt already loaded
• exports pixi and gets latest pixi as dependency

thanks to this you can include it multiple times with webpack or whatever bundler and you will not get Cannot redefine property isJson exception at browser runtime

[Prozi]

v1.2.1
updated yet again since installing dependencies for canvas is pain in the A$$ so I decided to instead depend on canvas-prebuilt that makes the installation so much smoother & seems to work still

[themoonrat]

Closing as the above shim solves! Thanks!

[lock]

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.