Pixi.js, WebGL, and NW.JS together

  • Still pretty new here, so let me know if this is not a good place for this question.

    I have a game that renders to a canvas and, based on the demos I’ve seen, I suspect it would run a lot faster with pixi.js’s WebGL rendering. The immediate issue with pixi.js is that you need a web server to serve image files, otherwise you run up against security restrictions in the browser. OK, so I would run a node http server, right?

    But here’s where I’m really confused. Do I need to have an http server running within my NW.js app? I know basically how to do this with node, but haven’t tried it in the context of NW. It doesn’t make sense to me how I’d select a non-privileged port to listen to and then know how to use that port to get the images. And in general it seems like massive overkill for such a simple (and I assume common) use case.

    There are also startup options that let you access files, but I don’t see how that would fit in with NW.

    Any thoughts?

  • Well, I feel pretty dumb. I put together a little demo, ran NW.js on it, and it worked out of the box. I was hesitant to even to even try this because I couldn’t understand HOW it could possibly work without a server.

    That flag I mentioned in my first post? Yea, they turn it on by default. You wouldn’t want to use this argument on your own browser for security reasons, but I suppose it’s perfectly fine for NW.

    I did learn that you can pass chromium arguments to NW.js. For a while I was using nw-builder and having some issues with it and recently found the lovely web2executable, which clued me into this fact (it has a GUI where you can set all the options and it saves them to your package.json).

    Oh well. Now onto actually trying to learn pixi!

  • Patron

    Good luck! :D

  • LDG

    Sounds like you got it figured out! PIXI is really fast (Phaser uses it under the hood) and was pretty easy to use if memory serves.

  • @jere said:

    Oh well. Now onto actually trying to learn pixi!


  • Well, PIXI really hasn’t been that hard. I didn’t see the performance gains I was hoping for, but anyway I’ve learned something for next time.

    I wrote a blog post about optimizing my game that ya’ll may find interesting (and there’s an anecdote about LDG): Tightening up the Graphics on Dungeon Floor 3

  • Jammer

    Curious where you are seeing performance drops. It’s hard to see gains when you might have a certain problem that a renderer cannot fix.

  • Here’s what the game needs to do: render roughly 400 tiles. Each one has a floor and potentially an item. Then I have to draw monsters separately. Then both tiles and monsters need lighting, so I’ve been using composite modes to achieve that. I didn’t think this was unreasonable for an HTML5 game.

    My experimentation with PIXI has been limited to buffers that I produce at the end of this process. I’ve got probably around 30 buffers that are each 640x32. When the player is idling (and that’s my first benchmark here), the only thing I’m doing is updating a handful of these buffers 10 times per second with a small modification and leaving the rest alone.

    Before PIXI, I had no problems getting 60fps on my PC, so that’s not really a use case. But I was trying to see if I could increase the performance on my MacBook Pro, which fluctuates around 30-50fps. I didn’t see any difference afterwards. I also have a linux VM, but for some reason (maybe someone here can help) I can’t get WebGL enabled in NW (even though it is clearly working in Chrome).

    Maybe I’m using PIXI improperly? No idea.

  • LDG

    Are you drawing off-screen tiles?

  • Nope, except the previously seen buffers may extend off the screen by a small amount.

  • @jere said:


    My guess is something funny is going on with those buffers.
    400 tiles is not much, and should render really fast even with a canvas renderer.

Log in to reply