cornerstonejs
Fix for WebGL Context Lost on Windows Devices with Integrated Intel GPUs
Seems like there is a bug in Chrome for Windows users with some models of the integrated Intel GPUs. As a result, OHIF and/or Cornerstone3D demos may experience rendering issues, with the GPU process consuming an excessive amount of memory for volume viewports. As a result, the webGL context may be lost and the browser crashes.
The bug has been narrowed down to be inside the Chrome and not from us, more especifically the Angle backend component of Chromium. While we are working on reporting this bug, we have a solution that has proven to be effective in fixing this issue which has worked on 4 separate machines having the same issue.
- Ensure that your GPU is not blacklisted by your browser. To enable ignore-blacklist, go to
chrome://flags/#ignore-gpu-blocklistand enable it. - Next, make sure that your browser is configured to use one of the following:
- Angle with the latest available WebGL backend (options are: d3d11on12, vulkan)
- Angle with OpenGL
For Chrome users, you can change your angle value by going to chrome://flags/#use-angle and changing the value as described.
(Note that your selected Angle must be supported by your graphics card and driver. While Chrome and Firefox will always display available options, it's important to check that your selected Angle is compatible with your machine.)
🎸 Special thanks to Rodolfo (@ladeirarodolfo )for finding this solution and sharing it with the community! 🎸
PS:
- For Mac users, we recommend using Default Angle settings.
- Firefox users, please navigate to https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers and refer to the section "How to force enable...." to enable ignore-blacklist.
This solution can solve the problem temporarily. I have tested and verified it on one computer.
@sedghi This solution seems to solve the problem with volume rendering. On stack vieports there also seems to be a problem with memory growing too fast on windows when I use CINE or change frame
@zhoualibaba can you please record your screen while you have the task manager open?
https://user-images.githubusercontent.com/17982206/225863603-fc9e674f-5bf7-46c1-923e-04abf5867652.mp4
@sedghi I have tried two ways to solve this bug. 1, Change the Google Chrome to the Chromium; 2, Seperate the multiple frames in one dcm file into a set of dcm files for each frame. The first way can solve the bug for most series, but if the frames count is too large (ie. 600+) the website will still crash. The second way can solve all the problems but I have to waste a lot of time to seperate the file.
Hey, thanks for sharing the video What happens if you use the stack viewport for that data?
can you create a new issue to discuss it there and we don't add noise here please?
I've tested this specific issue with VTK and found a promising solution.
When using a 512×512×800 vtkImageData, I was able to successfully open and manage 16 separate rendering windows using vtkWebGPURenderWindow without experiencing any context loss.
Since this configuration works reliably, I believe replacing the current use of vtkOpenGLRenderWindow with vtkWebGPURenderWindow will resolve the problem
