Instantiating more than 4 WebGLRenderers causes black textures

[erd0s]

If I instantiate and destroy more than 4 WebGLRenderers on a single page I get a black canvas, this behavior is consistent across chrome/ff/safari, I've included a minimal example, any ideas why this would be happening?

I'm in an "mvc" type page where the page is rarely refreshed, changing pages just swaps out content on the page, and my pages have a pixi instances on them.

var stage, renderer, container, redText, blueText, keepGoing;

var animate = function() {
    if (keepGoing) {
        requestAnimFrame(animate);
        renderer.render(stage);
    }
};

var startPixi = function() {
    stage = new PIXI.Stage();
    renderer = PIXI.autoDetectRenderer(1080, 393, {transparent: true});
    document.querySelector('body').appendChild(renderer.view);

    redText = PIXI.Sprite.fromImage("img/red-text.png");

    stage.addChild(redText);

    lastTime = new Date().getTime() / 1000;
    keepGoing = true;
    requestAnimFrame(animate);
};

var endPixi = function() {

    stage.removeChild(redText);

    redText.texture.destroy(true);
    keepGoing = false;
    renderer.destroy();

    var c = document.querySelector('canvas');
    document.querySelector('body').removeChild(c);
};

So calling startPixi() then endPixi() more than 4 times causes this behavior

[erd0s]

After testing further it appears that the texture's the problem. I noticed that redText.texture.baseTexture._glTextures is empty after the 5th renderer

[erd0s]

I think I found the problem! This will need some input from a maintainer tho, in WebGLSpriteBatch.prototype.renderBatch the _dirty array never has more than 4 elements. Once WebGLRenderer.gl.id is >= 4 the expression

if(texture._dirty[gl.id])

... always returns undefined and the texture is never updated with the current renderer. Although I'm not exactly sure what the process for setting textures as dirty is, or why there's only ever 4, or even what a dirty texture is.

I'm able to get around this problem by manually calling:

renderer.updateTexture(redTexture.texture.baseTexture);

Directly after I create the texture/sprite

Thoughts?

[franciscopreller]

Hey, I'm having this issue as well. Could anyone shed any light?

[alexmahan]

Ran into this issue as well with 5 renderers on the same page. A sprited icon in the last renderer would always render as a black square.

As suggested above, calling renderer.updateTexture(myIcon.texture.baseTexture); after the sprite is added fixes the issue.

[mattdesl]

The problem is because of this really ugly line:
https://github.com/GoodBoyDigital/pixi.js/blob/2dfd58b3757e16fad4b26a1fb9edf944f38aa5b8/src/pixi/textures/BaseTexture.js#L110

One fix would be to use an empty initial array for _dirty, and then do a check like this instead:

texture._dirty[gl.id] !== false

There are a lot of places in PIXI that do the above dirty check so the patch would actually have to go through and change all of them. Instead it would be better to avoid repetition by providing a getter or method to check "dirtyness" of a texture.

I think these problems would appear less if Pixi contributors / maintainers took the DRY principle more seriously.

EDIT: An alternative approach would be to make _dirty a getter (Object.defineProperty) that accesses something like __dirty and does the !== false check. This is getting kinda nasty though.

[noseglid]

I've run into this as well now. Is there a workaround for 2.x? I can't go back to 1.6.1 since I need features from 2.x.

[mattdesl]

@noseglid
you can just add a few more true's to the problematic code

😐

[noseglid]

Won't really help me.. I don't know how many I need.

[mattdesl]

Well most browsers aren't capable of handling more than a couple dozen, so that's a starting point. Why do you need so many?

Sent from my iPhone

On Jan 7, 2015, at 3:18 PM, Alexander Olsson notifications@github.com wrote:

Won't really help me.. I don't know how many I need.

—
Reply to this email directly or view it on GitHub.

[noseglid]

It's not that I have many at the same time. I create and destroy them as I go along.

My project is an SPA; so the page is never really reloaded.

[mattdesl]

In previous projects I've used a singleton to re-use canvas contexts, but that can arguably get annoying to test and also isn't easily supported by some frameworks.

I suspect even if this bug is fixed you will find other issues with Pixi not cleaning up resources from earlier renderers (just off the top of my head: the texture cache). 😞

[englercj]

This should be fixed now in v3. Using events from the texture that any number of renderers can listen for to update/destroy that 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.