How can I optimize drawing static lines?

[patrick99e99]

As I am animating various things being drawn to the canvas, I am also as a last step, drawing a large number of rows of broken up horizontal lines (these are static, that don't move or change in any way)...  As I was testing my game, I noticed that Firefox in particular was super choppy and laggy.  When I profiled, I saw the function call to the static lines was the thing taking up time. So I commented that out, and then Firefox ran fairly smoothly....

So now I am wondering, what alternatives do I have to how I am currently doing this? I was wondering if it would be a good idea to draw these the lines to a png buffer, and have pixi display that instead of manually drawing the lines on the canvas...  Are there any good techniques for improving performance of drawing large batches of disconnected lines?

Edited March 7, 2020 by patrick99e99

[patrick99e99]

I tried this, but it does not seem to work:  add a container to the stage and set my game's graphics context to a new one.. draw the lines one time, set the game's graphics context back to the original, set the cacheAsBitmap flag as true, and never do any more rendering for that again... Instead, I see the lines flicker one time and then are gone.. So seems I am perhaps misunderstanding how cacheAsBitmap should work?

 13     render: function(ctx) {
 14       if (this.cache) return;
 15
 16       var graphics = ctx.graphics;
 17       var container = new PIXI.Container();
 18       var overlay = new PIXI.Graphics();
 19       container.addChild(overlay);
 20       ctx.stage.interactive = true;
 21       ctx.stage.addChild(container);
 22       ctx.graphics = overlay;
 23       this.cache = { ctx: ctx, container: container };

 ...

 draw the lines

  ....

 78       this.cache.container.cacheAsBitmap = true;
 79       ctx.graphics = graphics;

 

[ivan.popelyshev]

Hi!

Congratulations , you managed to describe your problem in a way that i dont understand. At all. Individual words, such as " large batches of disconnected lines" and "cacheAsBitmap" make sense, but when you introduced "context" - i really dont understand what your context is. Are you using canvas2d context?

Maybe you are overcomplicating things. Static lines that arent re-filled in graphics every frame should go to separate graphics object, not the one you are clearing every frame. Using cacheAsBitmap on those will only slow down fragment shader, because lines are tiny and big sprite is not, especially if your lines cover space more than one screen.

Naybe my explanation will look weird for you like yours for me, but at the least i can suggest to read other threads in this forum, maybe the picture of how pixi draws stuff and what is slow will just weave from all that info.

A simple question: do you realize what is the difference between refilling graphics every frame and just moving it around with transform?

[ivan.popelyshev]

Pplease post your demo in jsfiddle, codepen or pixi-playground

[patrick99e99]

Sorry, when I said "context", I meant the Pixi graphics instance that is receiving moveTo() and lineTo() calls...

I am using a vector graphics game engine, and it uses Pixi under the hood.  Internally, there is one container,  one graphics instance that is used:

https://github.com/epmoyer/flynn/blob/master/js/lib/flynn/flynnCanvas.js#L158

So, basically what I was trying to describe before is, I have essentially what is like a "watermark"..  An overlay that sits on top of my game consisting of many, many lines..  So many that Firefox is slow to render them.  I am trying to understand what the best way to "cache" the watermark, since it does not change often, so that it is no longer a performance bottleneck to draw.

[ivan.popelyshev]

> I am using a vector graphics game engine, and it uses Pixi under the hood.

My condolences. Vector is trouble in WebGL world, of course we are working on fixing it but its always pain and its better if you know underlying webgl, at least read all Graphics module sources.

If your object is small, cacheAsBitmap can help you. If its big and lines cover only 1% of it while everything else is just space between them - dont use it. 

Basically, you have to understand that more vertices = buffer upload and vertex shader troulble. More pixels => fragment shader will be bottleneck. Buffer upload can be mitigated if you leave the graphics inners alone and modify only transform. If you have 1000 graphics elements - number of drawcalls will affect the webgl bus and most of the time program will just wait for sync commands between js and webgl threads. To balance everything , you need experience. Use profiler. Use https://spector.babylonjs.com/ to see how pixi generates webgl commands for single frame. Read all the threads on this subforum about performance - just search for this word in pixijs subforum, I and other people posted enough information, but we didn't make a single article about it because, duh, we dont have time, there are so many things to do: filters, stage, resizing , e.t.c. and vector is very difficult topic that no one in webgl world made correctly.

[patrick99e99]

Thank you for your reply.  So asking my question another way, would there be a way to draw these lines in a new PIXI.Graphics() object, and then store off the contents as a PNG sprite and then add that sprite back to the stage (so the individual lines do not need to be drawn more than one time)?  Would that result in a performance gain?

Edited March 8, 2020 by patrick99e99

[jonforum]

20 minutes ago, patrick99e99 said:

Thank you for your reply.  So asking my question another way, would there be a way to draw these lines in a new PIXI.Graphics() object, and then store off the contents as a PNG sprite and then add that sprite back to the stage (so the individual lines do not need to be drawn more than one time)?  Would that result in a performance gain?

is this can help you ?

https://www.pixiplayground.com/#/edit/iJSP1O9dmLpGUONUnIYBv

 

[patrick99e99]

Yes!  I believe that technique fixed my Firefox choppy performance!

Thank you!!