Multiple Canvas Renderers

[dszidi]

First off I would like to say hello to everybody. As a web developer that started off with AS3 I was very happy to discover pixi.js! Feels just like home. 

I was wondering about running multiple instances of PIXI.js using canvas instead of WebGL. I'm currently working on a project where we are using charts and data visualization and have been looking for alternative libraries. We're currently using SVG based C3.js and are running into performance issues. My options are:

1. Switch to another charting library that is canvas based (These are performant but not very extendable)
2. Make the jump to D3.js which could be made to use canvas (hacky + big learning curve)
3. Use a general purpose library for canvas. PIXI.js would also offer the bonus of WebGL based solutions for full screen visualizations. I could also use these skills for other things

I'm looking at #3. I know you can only have so many WebGL renderers on a page at once so I was wondering about forcing canvas.

TL;DR   How many canvases can I have up at once on a single page? Is this a bad idea? Just wanted to know before I invest a bunch of time on learning another library.

[Bart Read]

I'm not aware of a hard limit to the number of canvases you can have on a single page. However, things to bear in mind:

• Each canvas will need its own WebGL context
• WebGL contexts cannot share resources (e.g., textures, buffers), so if you have to load everything multiple times because you're duplicating content you can use a lot of memory. (You can do tricks with gl.viewport and gl.scissor on a bigger canvas to give the impression of multiple views, but this isn't my area of expertise.)
• Even when thinking about Canvas 2D, memory can become an issue on mobile devices. E.g., if you have a 1000 x 1000 pixel canvas, at 32 bits per pixel (with alpha transparency) this will require 4MB of storage. Manual double-buffering with canvas isn't necessary, but I have no idea if browsers implement full double-buffering behind the scenes: if they do that's 8MB. Either way, with multiple of these canvases the memory footprint can quickly add up.

So far I've only used multiple canvases with standard 2D rendering without issues: usually for background and foreground canvases. Sometimes I have a couple of extra hidden background canvases that I can fade between as required, although only in desktop browsers.

Anyway, multiple canvases is very much not a bad idea. You can, for example, paint a static background once on your background canvas, and just leave it there, rather than repaint it on every frame, which would be much more expensive, even if you were just blitting a large pre-rendered image. As already suggested, I do tend to restrict myself to two canvases total when running on mobile. All my canvases tend to be 1368 x 768, and then I rely on the browser's compositing engine to handle overlay and transparency, and scale up/down as appropriate for the window size/device screen (this process is generally GPU accelerated).

[mattstyles]

Multiple canvasses was one of the initial spec items for canvas usage, going as far as using it to render and animate iconography on a site. Not sure how that plays out with a webGL context or multiple large canvasses.

Having had to work with various charting and data visualisation tasks I wouldn't be keen to do this all manually unless I just wanted to learn how to do it. Pixi is a renderer, a really good one, but it won't help outrageously with creating charts and animating them. Compared to D3, for example, even with the D3 learning curve, you'll be up and running doing far more interesting things in a fraction of the time and a fraction of your own code.

Having said that, if what you have in mind isn't particularly friendly to do in D3 (or another lib) then using Pixi would be a great idea as you'll be doing a lot of manual work anyway.

[dszidi]

Thanks for the replies. Definitely some food for thought. I've done some preliminary research into how I could use D3 with canvas but it involves doing some things like creating the would-be DOM structure in memory. There were some other complications around user interaction with canvas+D3, although those may have been fixed with more recent versions.

Since I used to do a lot of Actionscript 3 back in the day, I'm not afraid of trying to do these charting tasks in pixi or even eventually figuring out how to get D3 to use pixi's classes/methods instead of SVG for drawing things out.  Also like I mentioned in my original post, getting familiar with pixi will have other benefits outside of my charting needs. 

In any case, I think I will give pixi a shot and put together a proof of concept. I'll do a line chart with 1 line and a lot of points and see how many canvas elements I can get onto a page. If that fails I'll go with D3  

[dszidi]

On 8/21/2018 at 4:24 PM, mattstyles said:

... Not sure how that plays out with a webGL context or multiple large canvasses...

Forgot to mention, I have two use cases,

1 - multiple smaller charts based on canvas 2d

2 - A single complex chart which I can use Pixi's default webgl renderer