OffscreenCanvas Support

HOOPS Communicator
1

After upgrading to Hoops Communicator 8.0, we encountered loading failures. Upon investigation, it seems the issue is related to the browser’s lack of support for the OffscreenCanvas API, which is not available in Safari versions prior to 16.4.

This issue did not occur with Hoops Communicator 5.0. I would like to clarify the following:

  1. Is OffscreenCanvas a mandatory dependency in Hoops Communicator 8.0?
  2. If a browser does not support OffscreenCanvas, is there any fallback mechanism provided?
  3. What are the recommended solutions for this issue?

Thank you for your assistance!

2

Hello @wwj8867486,

In the event that OffscreenCanvas is not available, the fallback is HTMLCanvasElement.

The current version of Safari is v18. Is there a particular reason upgrading from v16.4 is not a viable option?

Thanks,
Tino

3

Hi Tino,

Thank you for your response.

The fallback to HTMLCanvasElement is good to know. However, we are encountering issues where the application fails to load properly in Safari versions below 16.4. It seems that the fallback mechanism might not be functioning as expected, as the SCS files fail to load entirely in these cases.

As for upgrading Safari, while we understand the current version is v18, some of our users are on managed devices or legacy systems where upgrading beyond Safari 16.4 is not immediately feasible. This makes browser compatibility a key concern for us.

Could you confirm if Hoops Communicator has an automatic fallback mechanism to HTMLCanvasElement when OffscreenCanvas is not available? From our testing, it appears that Communicator does not handle this compatibility issue, which results in loading failures on unsupported browsers.

If no such mechanism exists, is there a recommended approach to address this scenario and ensure compatibility for users on older Safari versions?

Thank you for your assistance!

Best regards,
wwj8867486

4

Hi Tino,

I reviewed the source code and noticed that there is indeed a fallback mechanism in place to handle cases where OffscreenCanvas does not support webgl2. However, it seems that the implementation is missing a check for "OffscreenCanvas" in window. As a result, when OffscreenCanvas is not available in the browser, the line new OffscreenCanvas(...) will throw an error, preventing the code from reaching the fallback logic.

image
image2086×496 72.7 KB

To address this issue in my own code, I’ve implemented a workaround by first checking if "OffscreenCanvas" in window and whether it’s a valid constructor. If not, I define a fake OffscreenCanvas class that mimics its API but always returns null from getContext . This ensures that the fallback mechanism in the source code is triggered properly. Here’s an example of what I’ve done:

if (!("OffscreenCanvas" in window) || typeof OffscreenCanvas !== "function") {
  class FakeOffscreenCanvas {
    constructor(width, height) {
      this.width = width;
      this.height = height;
    }

    getContext(type) {
      console.debug(`FakeOffscreenCanvas: getContext("${type}") called`);
      return null; // Simulates unsupported WebGL2 context
    }
  }

  window.OffscreenCanvas = FakeOffscreenCanvas;
  console.debug("FakeOffscreenCanvas has been defined");
}

To improve compatibility, I suggest adding a check for "OffscreenCanvas" in window before attempting to instantiate OffscreenCanvas. This would ensure that the fallback mechanism is triggered correctly in environments where OffscreenCanvas is not supported (e.g., older versions of Safari).

Best regards,
wwj

1 Like