AbstractBatchRenderer caching null textures

[Janne]

Hello,

It's been a long while since I touched pixi.js and trying to update it from 4 to 5. For some reason I stumble upon a situation where the AbstractBatchRenderer has undefined _bufferedTextures. So what seems to happen is that I call the renderer in one place once and it renderd 7 textures. Then later on I call it in another place and since the buildTexturesAndDrawCalls sets the _bufferedTextures to false it still holds those values. So it looks like this on the first run:
[ object x 7 ] and after the run [null x 7] after the render-call.

Then it gets called another time and it still holds the references to those null-values as in:
[ null x 7, object x 100] and errors as there are nulls.

I don't understand what happens there, why does the render have an internal textureBuffer counter and why does it make the texture-references to become as null values and retains them on the next run? How should it be executed to make the render happen correctly with the BatchRenderer?

The code in question is in render and in buildTexturesAndDrawCalls-calls
https://github.com/pixijs/pixijs/blob/170e890aad69828c394417cafbb3c0a0d928e8d3/packages/core/src/batch/AbstractBatchRenderer.ts#L389
https://github.com/pixijs/pixijs/blob/170e890aad69828c394417cafbb3c0a0d928e8d3/packages/core/src/batch/AbstractBatchRenderer.ts#L414

[ivan.popelyshev]

Need more details. Are you trying to update to latest v5 or some old v5 just to update 5.1 5.2 5.3 and so on ?

Everything should work.

Do you happen to have two renderers at the same time? like, pixi and threejs or two versions of pixi?

[ivan.popelyshev]

oh, right, its LATEST.

that "textures" array holds textures of sprite in the queue. We dont resize it usually, we clean it up by setting elements to null 

[ivan.popelyshev]

1. render() method ads a texture in array: 

https://github.com/pixijs/pixijs/blob/170e890aad69828c394417cafbb3c0a0d928e8d3/packages/core/src/batch/AbstractBatchRenderer.ts#L388

2. Flush calls several methods and then sets bufferSize to 0: https://github.com/pixijs/pixijs/blob/170e890aad69828c394417cafbb3c0a0d928e8d3/packages/core/src/batch/AbstractBatchRenderer.ts#L605-L610

3. inside flush, buildTexturesAndDrawCalls goes through whole buffer and sets textures to null, because they wont be needed anymore: https://github.com/pixijs/pixijs/blob/170e890aad69828c394417cafbb3c0a0d928e8d3/packages/core/src/batch/AbstractBatchRenderer.ts#L410-L414

If you found the case when _bufferSize=0 , and array holds actual textures and not nulls - then we have a bug. Do you have a reproduction?

Edited July 11, 2021 by ivan.popelyshev

[Janne]

Thanks for the explanation, after understanding that flush is setting the bufferSize to 0, I got the idea.

I was looking at the wrong problem. The bufferSize doesn't get set to 0, because there was an error before it does that. The error occurs, because for some reason PIXI.Texture.from returned and incorrect object (due to some version missmathces).

It must have been an issue with versions. There are 2 repositories in the same project and originally I just npm installed the default one (which is 6.0.4 I believe). For some reason it gave me issues and figured there might be issues with it and installed 5.2.4. Then it was complaining that the texture doesn't have .castToBaseTexture-method (even though some of them did have). I probably had different versions on the projects, even though I tries to make sure they are the same.

As a side-note (I could have put this to the github, but didn't yet at least). When installing pixi.js from npm, it installs the 6.x.x version. I had the same issue with that, so didn't report that yet as I don't know if it's on purpose (and the 6-version would be fairly stable). Since my understanding was that 5 is the latest stable version and 6 is still underway.

Thank you for the help! Understanding that buffer functionality really helped me to track it down better! This seemed to be the only big issue I really had with migrating from 4 to 5 (or in this case 6)

[ivan.popelyshev]

6 is stable. ITs almost the same as 5, just with different typings/modules. There are no breaking changes, just removed deprecations.

Edited July 13, 2021 by ivan.popelyshev