how to render 30 animating lines with 2500 points each at 60fps

[jojoba]

Greetings!

I love pixijs! Amazing stuff!

I'm currently attempting to plot about 30 lines, each containing about 2500 points scrolling right to left (where once a point goes off the screen to the left, a new point is appended on the right). Think a whole bunch of streaming time series charts.

I've been able to plot them out, creating a top level PIXI.Container to contain all the lines, and then for each line, creating a PIXI.Graphics object that I addChild to the top level PIXI.Container, setting the line style and then in the render loop going thru each line's 2500 points and doing the moveto lineto fun. It works! However my framerate peaks at around 40fps, which is still nice, but hoping for a 60fps. Note: I do the line moveto and lineto for each line before I call the render on the top level PIXI.Container, so hopefully that's forcing all the draw work to happen in one frame.

Does anyone happen to know if there any optimizations that I could leverage to speed this up?

Thank you kindly for any help you can offer.

Cheers!

[ivan.popelyshev]

You can try use nativeLine, but you wont be able to set the width of it:

var graphics = new PIXI.Graphics(true);

 

[ivan.popelyshev]

Also, if you update Graphics often, its better to add to the end => may be use chunks (different PIXI.Graphics) and drop/add a number of points (~100) instead of doing it one-by-one. 

[jojoba]

Thanks Ivan for responding so fast!

I tried var graphics = new PIXI.Graphics(true) and it bumped up my framerate to 45fps, which is better!

Regarding your second comment, about adding points in chunks, I'm not sure I understand entirely. I am updating my data at 60Hz (remove the first element, and append a new element) and then in a requestanimationframe, am using a PIXI.Graphics to lineto and moveto the line for each point in my data for each line, and then call render. Where would the chunking occur exactly?

 

Thanks for all of your help! I very much appreciate it.

[ivan.popelyshev]

One Graphics element is drawn with one drawcall. If you use many "moveTo-lineTo" inside, it will all go into one call (batched). However, each time you change Graphics, it re-uploads buffers into GPU, and instead of just asking "hey, please draw that thing I sent you some time ago" it uploads new data, which affects performance.

You have to maintain multiple Graphics elements, for example, 1 for every 100 points. 

Instead of clearing the graphics and adding all data again, you should rarely create new Graphics and dump 100 new points there. Also you can use that fact that changing transform (position,scale) of graphics is very cheap. You can just generate some points ahead every X frames, and move all container (or every graphics element) to the left every frame.

List of operations:

1. Use one graphics per one segment of line - most expensive operation here

2. Use graphics per thousands of points, clear and fill it again every frame - just expensive

3. Moving existing graphics element without actually changing contents - cheap.

4. Adding graphics with 100 points one time in several frames - cheap.

Note, that we are talking about "expensive" relatively your case - several lines each of thousands of points. There are much more expensive operations in PIXI and in webgl in general.

[jojoba]

Ah, thank you for the clear explanation. Now I understand what you mean by chunking. This helps so much!!

[ivan.popelyshev]

Dont forget to like that post ^^^^

Also, write here when you achieve 60FPS, and try to add some lines to measure how many lines with how many points it can handle.

[dmko]

On 9/13/2017 at 12:38 PM, ivan.popelyshev said:

Use graphics per thousands of points, clear and fill it again every frame - just expensive

This is surprising to me! I would have thought that a graphics item doesn't really care much about what's in it, more like the size of it. Interesting

[ivan.popelyshev]

17 minutes ago, dmko said:

This is surprising to me! I would have thought that a graphics item doesn't really care much about what's in it, more like the size of it. Interesting

If you dont refill it every frame its much cheaper. There's penalty for refill, but yeah, everything also depends on size.

[dmko]

When you have time, can you explain a bit more about the reason behind that? Is it on the JS side or WebGL side?

I'm only starting very very slowly to get into webgl stuff... really don't know what I'm talking about yet (waiting for first book to arrive!) - but I'd think that filling a buffer with different data is relatively cheap?

[ivan.popelyshev]

Its cheap, but when there are 10k or so elements its cheaper to not the fill the buffer and just use the one we already have uploaded.

[dmko]

So it's more on the js side? e.g. the WebGL side sees an array of values and uploads it to the buffer when there's a change, regardless of how much of it changed, but the JS side populates those values through lots of processing?

[ivan.popelyshev]

Yes, it can be divided into JS generating values and calling webgl upload operation, which also eats CPU. Existing buffer doesnt need that.

[4Be]

In three.js it's possible to call

.setDrawRange(start, end)

on a BufferGeometry, so we can maintain 5000 points on the gpu (for example), and then draw a subset from those, which is very efficient for growing drawings (the trail of a pencil, a plant growing, etc). Do I understand correctly that this is not possible with pixi.js? Thanks!

[ivan.popelyshev]

4 hours ago, abe said:

In three.js it's possible to call

.setDrawRange(start, end)

on a BufferGeometry, so we can maintain 5000 points on the gpu (for example), and then draw a subset from those, which is very efficient for growing drawings (the trail of a pencil, a plant growing, etc). Do I understand correctly that this is not possible with pixi.js? Thanks!

Its possible, but it requires complete knowledge on how Graphics work. I just have too many things to take care of in v5 to do that right now

If you do that, please publish the snippet, I'll add it to wiki.