WebGLRenderer.addDisplayObject issue

[fangcan]

when a new sprite is added to stage,pixi look for the closet previous sprite and next sprite and then insert after or insert before one of the both.Is it to let the Web GLBatch draw order and display tree order consistent?but I think it doesn't gurantee that all the sprites with the same texture and blend mode were group into the same WebGLBatch.so may it affect efficiency?

[GoodBoyDigital]

Hi Fangcan,

Each time a sprite is added to the webGL render list it is tested to see if it can be grouped into a webGLBatch adjacent to it. At the moment this test checks that the baseTexture is the same and that the blendMode is the same using this line:

if(nextBatch.texture == displayObject.texture.baseTexture && nextBatch.blendMode == displayObject.blendMode)

This ultimately preserves the display tree order, meaning that pixi.js does not need to enable the webGL zBuffer. This keeps things ticking over a lot faster.

One of the tricks that makes pixi.js extra fast is that the webGL render only modifies the batches when an object is added or removed. Most other 2D engines recrawl the scene graph every frame. Pixi.js does not and this makes it extra fast :)

[fangcan]

Thanks for reply. I use pixi on Nexus S mobile phone of android 4.0.3 with firefox mobile browser.and I made some changes as follows:
No.1:
while(!previousSprite.renderable || !previousSprite.__inWebGL || previousSprite.batch.texture !=displayObject.texture.baseTexture || previousSprite.batch.blendMode != displayObject.blendMode)
No.2:
at WebGLBatch.render function:
if(this.dirtyPosition){
gl.bufferSubData(gl.ARRAY_BUFFER, 0, this.verticies);
this.dirtyPosition=false;
}
//the dirtyPostion was computed by some code which is not shown here;
Then a great rendering performance improved by these changes;
So did pixi consider rendering performce of moble platform like android ? Based on my experience,the Copy from CPU memory to GPU memory and more WebGLBatches has taken huge performance overhead on android. But now pixi has taken a vertex position vbo update completely every frame which really did costs a lot.

[GoodBoyDigital]

Good stuff! Im very curious about your first point. If you could you explain it in a little more context that would be super helpful.

Pixi.js' performance was considered for mobile by making the whole renderer as light as possible in terms code executed on the CPU on each update. Totally appreciate what your saying about there being a small overhead between CPU and GPU communication, one that hopefully is outweighed by the speed increase that webGL offers?

Interesting to know that your tests show that the overhead of checking the dirtyPosition variable each frame is cheaper than uploading the positions each frame. Is this an android specific thing? Does this hold true with larger batches?

Thanks again for looking into all this, its most helpful! Lets see if we can squeeze even more speed out of pixi.js :D

[fangcan]

my first point is just like this(pay attention to the last line):
/*
* LOOK FOR THE PREVIOUS SPRITE
* This part looks for the closest previous sprite that can go into a batch
* It keeps going back until it finds a sprite or the stage
*/
var previousSprite = displayObject;
do
{
if(previousSprite.childIndex == 0)
{
previousSprite = previousSprite.parent;

    }
    else
    {
        previousSprite = previousSprite.parent.children[previousSprite.childIndex-1];
        // what if the bloop has children???
        while(previousSprite.children.length != 0)
        {
            // keep diggin till we get to the last child
            previousSprite = previousSprite.children[previousSprite.children.length-1];
        }
    }

    if(previousSprite == displayObject.stage)break;
}
while(!previousSprite.renderable || !previousSprite.__inWebGL || previousSprite.batch.texture !=displayObject.texture.baseTexture || previousSprite.batch.blendMode != displayObject.blendMode)

[fangcan]

you say to preserves the display tree order,a new sprite is just grouped into a WebGLBatch adjacent to it.But this will also cause to increase the amount of WebGLBatches which will affect the rendering efficiency specificially on mobile platform.so can why think a way to solve the drawing order but also make fewer WebGLBatches?

[GoodBoyDigital]

Yes thats true, thats to preserve the order of the sprites. The best way to solve this is to use sprite sheets so that multiple images all share one texture. That way the will get batched up and draw super fast.

Our demo game run pixi run uses only 1 images for the main game assets:

http://www.goodboydigital.com/runpixierun/img/WorldAssets-hd.png

This means that it runs super fast as most elements in the game are batched because they share a texture.

[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.