Safari performance loss when rendering a 2D texture generated by PixiJS

Questions
1

Hi there,
My team and I are currently working on having a Three scene rendering Three objects as well as a 2D plane with a CanvasTexture that PixiJS uses to render.

The thing is that we see a drastic performance loss on Safari.
Here is an example with 2 situations:

You can see that the textSubImage2dD takes a lot of time here:

screenshot_textSubImage2d
screenshot_textSubImage2d1132×538 146 KB

I think this issue is similar to Performance issue with CanvasTexture and needsUpdate on every frame (LottieLoader use-case scenario)

Do you know why Safari would handle this so much differently than other browsers?

2

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

Thanks for suggesting these @Mugen87. I’m working with @alexandresi on this.

  • 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:

    texture.generateMipmaps = false; 
texture.minFilter = THREE.LinearFilter; 
texture.wrapS = THREE.ClampToEdgeWrapping; 
texture.wrapT = THREE.ClampToEdgeWrapping;

    but no impact on performance too.

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.

4

If you not explicitly define the encoding/color space then you can forget about my point. It would only be relevant if you did something like this before:

texture.encoding = THREE.sRGBEncoding;
5

Texture uploads per frame should not degrade your performance that much. I suspect this is a Webkit issue that we can’t fix on engine level.

You probably want to file an issue at the Webkit bug tracker: https://bugs.webkit.org/