I don’t know why this happens. But do you mind testing two things:
Do you see better performance by using WebGL1Renderer? I just want to rule out WebGL 2 specific issues.
Do you mind not changing the encoding/colorSpace texture property of your canvas texture? I have not studied your app code so I don’t know if you are using a sRGB workflow. But for testing, I would be interesting to know if gl.SRGB8_ALPHA8 makes issues.
It seems that using WebGL1Renderer for the three.js rendering is not changing anything performance wise (still super slow in Safari, no visible difference) (still fast in Chrome). Note that the PixiJS rendering is still done with WebGL 2 (but the Safari dev tools confirmed the three.js canvas was using WebGL and not WebGL 2).
For " not changing the encoding /colorSpace texture property of your canvas texture", I’m not sure exactly how we can check that. The texture is created by doing new THREE.CanvasTexture(pixiCanvas) . It’s actually done twice, we have two textures like this reading from the same canvas.
We also tried to disable mipmaps on the texture that is read from the PixiJS canvas:
For the sRGB workflow, do you suggest trying something different?
Just to make sure it’s clear: the texture read from the PixiJS canvas has needsUpdate = true set at each frame so that the 2D rendering from PixiJS can be displayed “in real time” in Three.js. I see how can this be an intensive operation but would still expect fairly good performance especially on recent devices.