WebGL context lost after multiple model switches, followed by slow WebSocket binary streaming

General
, , ,
1

We are facing an issue with HOOPS Communicator (WebGL) where the WebGL context is lost automatically after multiple model switches (no explicit WEBGL_lose_context call from our side).

After the context loss:

  • On page refresh, the WebSocket reconnects successfully

  • Binary WebSocket messages (geometry streaming) comming very slowly

  • Viewer eventually recovers, but initial load is significantly delayed

This does not happen on a clean page load.
It only occurs after repeated model switching within the same session.

Observed Behavior

  1. Switch models multiple times in the same page

  2. Viewer triggers WebGL context loss automatically

  3. Viewer becomes unstable / reload required

  4. After refresh:

    • WebSocket connection is Pending (open)

    • Binary WS messages are received very slowly

    • Streaming speed gradually improves over time

Expected Behavior

  • WebGL context should not be lost during normal model switching

  • GPU resources should be fully released when a model/viewer is destroyed

  • WebSocket streaming should resume at normal speed after refresh

Current Cleanup Steps

During model switch we:

  • Call viewer.shutdown()

  • Remove the viewer canvas from the DOM

  • Dispose 2D and 3D viewers

  • Clear references to viewer objects

Despite this, GPU memory seems to accumulate, leading to forced context loss.

Questions

  1. Are there any additional APIs or best practices recommended by HOOPS to:

    • Fully release GPU / WebGL resources when switching models?

  2. Is there a known limitation or required delay between viewer destruction and creation?

  3. Can slow WebSocket binary streaming after context loss indicate:

    • Server-side throttling?

    • Client recovery mode?

  4. Is there a recommended way to detect and prevent GPU memory buildup during repeated model switching?

  • We are not manually calling WEBGL_lose_context

  • Context loss appears to be browser-initiated due to GPU pressure

  • The slow WebSocket behavior seems to be a side effect, not the root cause

Any guidance from the HOOPS team would be greatly appreciated.

we are in Version : 2023_SP1

2

Hello @raja.r,

Just a couple of things regarding your post:

  • You are using an older version of the now-called Visualize Web, that being HC 2023 SP1. The most current version is v2025.9.0 with v2026 slated to be released later this month.
    Are you able to test on a more recent version? There is a chance that your issue might have been addressed already given that we’ve improved the Server and other components.
  • Because you are creating multiple viewers in a session, you can check the status of the spawns by running this command after an instance is created and deleted:curl -X GET http://localhost:11182/api/spawns. This command will show all spawned instances. If there are more instances than created, then an instance was not properly handled. We’ve made improvements in this regard on versions more recent than HC 2023 SP1.

Thanks,
Tino