What does this sad face mean?

[blakjak44]

I have seen this sad face pop up from time to time in my application and I can't figure out what causes it. Maybe the renderer is unhappy?

[ivan.popelyshev]

Hello!

Usually its memory problem. Did you try to show million sprites there with 100 textures of 8192x8192?

[Shukant Pal]

This looks like a browser-specific issue. Can you tell us the platform you’re testing on? Does it appear in multiple browsers?

[blakjak44]

Thanks for the fast response! I'm actually using electron, so chrome-based. And yes, I am rendering a lot of large textures - about 90 1920x1920. 

My application is for scientific purposes and I need to display 40-100 grayscale images at a time. However, each image contains 2 or more channels so I render each channel as a separate mesh and just use change the alpha. The raw images are 16bit but it doesn't look like pixi supports sampling integer uniforms so, so I convert to 32bit before passing to the mesh. 

I'm sure I'm not doing this as efficiently as possible. Perhaps you guys can offer some advice on how to optimize?

One last thing, the meshes render fine initially. This issue happens after several cycles of clearing and loading new meshes, even though I thought I was correctly destroying the mesh when I'm done with them.

[jonforum]

3 hours ago, blakjak44 said:

Thanks for the fast response! I'm actually using electron, so chrome-based. And yes, I am rendering a lot of large textures - about 90 1920x1920. 

Try inject some flags 
https://peter.sh/experiments/chromium-command-line-switches/

look maybe for 
--enable-zero-copy ⊗
--enable-gpu-memory-buffer-compositor-resources ⊗
--enable-native-gpu-memory-buffers ⊗
--force-gpu-mem-available-mb ⊗
--force-gpu-rasterization ⊗
--full-memory-crash-report ⊗
--gpu-program-cache-size-kb ⊗
--ChromeOSMemoryPressureHandling ⊗
You have maybe more related, try and see if you can fix by args.
In my game i use a lot of stuff all are very huge resolution, and never get crash, but have a lot of args hack on nwjs for the chromium engine.
You can do the same thing with electron am sure.

[ivan.popelyshev]

13 hours ago, blakjak44 said:

Thanks for the fast response! I'm actually using electron, so chrome-based. And yes, I am rendering a lot of large textures - about 90 1920x1920. 

My application is for scientific purposes and I need to display 40-100 grayscale images at a time. However, each image contains 2 or more channels so I render each channel as a separate mesh and just use change the alpha. The raw images are 16bit but it doesn't look like pixi supports sampling integer uniforms so, so I convert to 32bit before passing to the mesh. 

I'm sure I'm not doing this as efficiently as possible. Perhaps you guys can offer some advice on how to optimize?

One last thing, the meshes render fine initially. This issue happens after several cycles of clearing and loading new meshes, even though I thought I was correctly destroying the mesh when I'm done with them.

That's interesting. Maybe its destroy bug.

Or maybe you dont use all textures at first, so pixi doesnt actually upload them all to memory. When it does - everything crashes. 90 x 1920 x 1920 x 4 bytes = 1.3 gigs. And both videomemory and regular one will have that for some time, of course regular will go away and only PNG will remain. You can also try to use DDS format instead (dont forget to gzip it for faster transmission), but it affects quality.

Here's the thread on how to use other texture formats for your texture. We cant possibly predict all the users need for their textures, so we allow to override texture uploading algorithm. Pixi will deal with all stupid things like bindings, you call "texImage2D".

 

Edited April 12, 2020 by ivan.popelyshev

[blakjak44]

@ivan.popelyshev @jonforum @Shukant Pal

Sorry for the late reply guys. Didn't have a chance to revisit this issue for some time. So it turns out that I was stupidly creating too many WebGL contexts (as I was using multiple PIXI Application instances for various UI control elements). Eventually I must have hit the WebGL context limit and that caused it to crash.

I fixed the issue by making all other PIXI Applications use the canvas renderer. Thanks for the help!