[Bug] [WebGL] Large Series Will Not Render (2800+ Frames)

[canhhuy116]

Describe the Bug

I'm encountering issues rendering a large DICOM series (2800+ frames) on OHIF Viewer 3.8.3 across multiple platforms. Following issue #3207, I managed to get the series to render on Chrome (version 130) with Mac Intel by setting the angle graphics backend to OpenGL. However, this workaround does not apply to Windows Intel or Mac Pro M1, where the series fails to render.

Configuration

• OHIF Version: 3.8.3

• Operating Systems:

  • Mac Intel core i9, Graphics: [Radeon Pro 560X 4 GB, Intel UHD Graphics 630 1536 MB] (working with OpenGL backend)
  • Windows Intel (not working)
  • Mac Pro M1 (not working)

• OHIF Config:

  • preferSizeOverAccuracy: true
  • useSharedArrayBuffer: 'FALSE'

Behavior

Before changing the setting angle graphics backend to OpenGL on Mac Intel

After change on Mac Intel:

Steps to Reproduce

1. Load a DICOM series with more than 2800 frames on Chrome.
2. Use the OpenGL backend on Mac Intel, where the series renders successfully.
3. Attempt the same rendering on Chrome (Windows Intel and Mac Pro M1) without success.

The current behavior

• Mac Intel: Series renders successfully when the angle graphics backend is set to OpenGL.

• Windows Intel and Mac Pro M1: Series fails to render, and the OpenGL backend setting does not resolve the issue.

The expected behavior

The series should render consistently across all platforms without requiring ANGLE graphics backend configurations.

OS

macOs 15.0.1

Node version

18.20.4

Browser

Chrome 130.0.6723.92

[sedghi]

2800 frames are a lot to gpu render i guess, what is the https://webglreport.com/?v=2 for you?

[canhhuy116]

Thank you for your response! Here is the output from webglreport for my system:

WebGL report for Mac Intel

1. Angle graphics backend default
   
2. Angle graphics backend OpenGL
   



[sedghi]

You have the norm16 texture extension, so the recent update for OHIF should help, can you try in the latest master branch?

[canhhuy116]

I tested on the latest master branch, but unfortunately, it still doesn’t work for my case. I also enabled the useNorm16Texture configuration with true, but the large series (2800+ frames) still fails to render consistently across my devices

[sedghi]

We can't render the full texture because the maximum 3D texture size in WebGL is 2048, and your texture size in one dimension is 2800. This PR attempts to divide the data into smaller portions to load them together as a workaround. Feel free to review it, but I don't plan to address this soon.

[sedghi]

Maybe if you rebase the old code and add some tests we can merge it

[canhhuy116]

Thanks for the update! I’ll rebase the PR and test it with my setup to see if dividing the data improves rendering. I’ll let you know if it resolves the issue.

[salimkanoun]

+1 it would be a very nice addition as we are also facing this limitation for some images

[canhhuy116]

I rebased the PR and tested it with my setup (>2800 frames). The images now display correctly after setting maxFrameInVolume = 2048 (matching the maximum 3D texture size for WebGL). Of course, this approach does omit some frames, which could be critical—an issue @wayfarer3130 mentioned in the PR. I’ll proceed with this solution for now, but I’d be grateful for any official handling for such cases in the future. Thank you!

[sedghi]

Keep the frames intact; just divide them into zones: head, shoulders, and chest etc...