Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some graphics and sprites do not render after WebGL context loss #7206

Closed
rj3d opened this issue Jan 27, 2021 · 1 comment
Closed

Some graphics and sprites do not render after WebGL context loss #7206

rj3d opened this issue Jan 27, 2021 · 1 comment
Labels
Stale Previously “Won’t Fix”, bots should tag with this for inactive issues or pull-requests.

Comments

@rj3d
Copy link

rj3d commented Jan 27, 2021

Hello! First and foremost, thanks for building such a powerful and friendly library!

Overview

I've developed an open source application called Mantis Viewer that is being used by a few scientific institutions to visualize and analyze microscopy data. We started this project a couple of years ago, and it's built using TypeScript, Electron, React, MobX, and PixiJS. Currently, it's being used by the institute I work for to analyze data from our clinical trials, and is also being used by labs at Stanford and UCLA to develop new microscope technologies.

Recently, a few users have been running into an issue where the WebGL context gets lost, and the renderer then fails to load (almost) everything after that. I've started to debug this and have built out some code to simulate a WebGL context loss on the canvas and recover. The code I've written works for a simulated context loss using webgl2Context.getExtension('WEBGL_lose_context')?.loseContext(), but fails to recover in real world examples that are, unfortunately, difficult to replicate.

I'm the sole developer on this, and this project is my first Electron, React, and PixiJS project. It's entirely possible that I'm using something (or lots of things) incorrectly that's causing this issue. I'm open to any feedback for things I could change in the linked code that could improve this issue, or anything else that I haven't run into yet for that matter.

Expected Behavior

After a WebGL context loss graphics objects and sprites should render.

Current Behavior

After a WebGL context loss graphics objects are not rendering. This is what an rendered image with annotations looks like initially:

image (1)

Immediately after this type of WebGL context loss and recovery, everything fails to render except for the text of the legend in the top left.

image (2)

If the user switches to a different set of images, the image sprites will load again, but the legend background (graphics object), zoom inset (graphics object), cell annotations (graphics object), and regions of interest (sprite created from graphics object pixel extract) still won't load. If they switch back to the first set of images where the context was originally lost, those image sprites will still fail to load.

image

Steps to Reproduce

Unfortunately this bug is pretty difficult to reproduce and might be dependent on the graphics capabilities of the system. I've only been able to reproduce this bug once on my system, but I have some users who are able to reproduce it within a couple of minutes. If anyone is interested in trying to reproduce it, I'd be happy to share a few images that you can play with and one of the test builds.

The project is open source, and I'm happy to share the code that's failing though. Most of our image rendering and interaction code is in this ImageViewer React component, which links to a branch where I'm actively working on debugging this issue. Currently the function that deals with handling a WebGL context loss is called handleWebGlContextLost and is on line 600 of ImageViewer. The other bulk of PIXI related code can be found in the GraphicsHelper module.

Environment

  • pixi.js version: 5.3.7
  • Browser & Version: Chrome 87.0.4280.141 as part of Electron 11.2.0
  • OS & Version: macOS Catalina 10.15.7
@stale
Copy link

stale bot commented Jun 2, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale Previously “Won’t Fix”, bots should tag with this for inactive issues or pull-requests. label Jun 2, 2021
@stale stale bot closed this as completed Jun 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Previously “Won’t Fix”, bots should tag with this for inactive issues or pull-requests.
Projects
None yet
Development

No branches or pull requests

1 participant