webgl branch: performance improvement for WL
See original GitHub issueHi, I’m trying out cornerstone-webgl (actually OHIF) for a test viewer for a DICOM store of X-Rays. I had a problem that the performance was quite bad. This is because the X-Ray images we have are of a size 4248x3480. The webGL render with the shaders seemed to be fast (good fps), but there was a bad lag in user interaction.
Eventually I found out that in a simple test of a webl canvas of size 4248x3480, even running just glClear on the canvas as the user moves the mouse led to pretty bad performance. So I decided to try to change the way the webgl renders, so that the webgl canvas is of the same size as the enabled canvas, and the view transform happens in the vertex shader.
It worked, and here are the changes I made. cornerstone_webgl.patch.txt
In OHIF, I also needed to make one change in imageViewerViewport.js, I’m guessing because OHIF has a slightly older version of cornerstone in it
--- imageViewerViewport.orig.js 2016-07-21 13:41:05.775327411 +0300
+++ imageViewerViewport.js 2016-07-21 13:11:34.248607304 +0300
@@ -124,7 +124,7 @@
// NOTE: This uses the experimental WebGL renderer for Cornerstone!
// If you have problems, replace it with this line instead:
// cornerstone.enable(element);
- cornerstone.enable(element, cornerstone.webgl.renderer.render);
+ cornerstone.enable(element, {renderer: 'webgl'});
// Get the handler functions that will run when loading has finished or thrown
// an error. These are used to show/hide loading / error text boxes on each viewport.
However this still doesn’t work on a number of PCs, because the texture is so big. I’m not sure if something like a texture array would help with this.
Issue Analytics
- State:
- Created 7 years ago
- Comments:9 (3 by maintainers)
Hi dannyrb, That sounds good. At the facility where I first tried this, we also reverted to using the standard version and don’t have performance issues anymore. Matthew
On Sun, Mar 24, 2019, 5:31 AM Danny Brown, notifications@github.com wrote:
This issue is creeping up on > 3 years old. Personally, I have not encountered WebGL performance issues. If someone feels this is still a good candidate for optimization/improvement, it would be best to create a new issue for discussion along with any ideas/suggestions you may have.