Why don't you just set the size of the node texture instead of changing the size of the jit.gl.slab? If you want to do this only with 2 chains then I would manually create two slab chains with different textures input instead of using that convoluted system.

Yes, the uzi part is really the problem, without it I go from 12fps to 430fps

I'm pretty sure Tarik's patch is simply for demonstrating the issue.

unfortunately I don't have a lot to say about it. changing dims and changing type requires rebuilding the texture, which is an expensive process. I don't think there's much we can do, as this is driver level. So my suggestion would be to catch any dimension changes as far up the chain as possible, and perform a resize to match the chain dims there.

Thanks all & thanks Rob!

Yes, my patches here are indeed meant just to demonstrate the issue. So, yes this issue is simply what it is, and I noticed that also on Mac this rebuilding costs time, it just seems to be less severe than on windows. But okay, accepted.

So I decided to build several chains in stead, one for each resolution/type combination that I want to use. To my surprise I saw that just the existence of these extra slabs in my patch would slow down rendering. Even if they're disabled and with automatic 0. Also this is only properly noticeable on windows!

My gpu seems to have plenty of memory left, so I don't think that's the issue? Any clue what is it that these idle slabs are doing to slow down the rendering?

Here's a patch demonstrating the issue:

Oh, sorry, I looked this too quickly.. The second patch is very clear. Interesting, this slab slow down, I'm also curious to know. I didn't really noticed it in my patches, but i have regularily slab and gl.pix that I enable/disable (not that much thought) and it's good to know if it impacts the performance