Can you describe a bit more about what you are trying to do?

For my specific use case, I'm making a map displaying a high number of pins on a massive display, specifically 9 4K screens in a 3x3 grid. Due to the size and resolution of this map, aliasing effects are highly visible. Pin images are either a SVG or a PNG (the difference isn't relevant as aliasing is visible on both). Pins are rendered and animated with custom shaders using a WebGLPointsRenderer.

As an alternative, you could try setting a higher pixelRatio on your map, e.g.

new Map({
  // ...
  pixelRatio: devicePixelRatio * 2
});

Maybe the result will be a canvas that is too big for the browser to handle, but at least it's worth a try.

This solution did work, at the expense of frame rate. However, the frame rate is still good enough for this to work for me, thank you!

All that being said, I still think it would be beneficial to add WebGL2 support. Starting to do so would be a simple change to the getContext function in src/ol/webgl.js. One possible implementation could be

// src/ol/webgl.js (CONTEXT_IDS declared on line 86)
/**
 * @const
 * @type {Array<string>}
 */
const CONTEXT_IDS = ['experimental-webgl', 'webgl', 'webkit-3d', 'moz-webgl'];

/**
 * @param {HTMLCanvasElement} canvas Canvas.
 * @param {Object} [opt_attributes] Attributes.
 * @param {boolean} [request_webgl2] Attempt to get a {@link WebGL2RenderingContext}, falling back to WebGL1. Defaults to `false`.
 * @return {WebGLRenderingContext | WebGL2RenderingContext} WebGL rendering context. if `request_webgl2` is `true` and WebGL2 is available, a {@link WebGL2RenderingContext} is returned.
 */
export function getContext(canvas, opt_attributes, request_webgl2 = false) {
  const attributes = assign({preserveDrawingBuffer: true}, opt_attributes);
  const contextsToTry = request_webgl2 ? ['webgl2', ...CONTEXT_IDS] : CONTEXT_IDS
  for (const id of contextsToTry) {
    try {
      const context = canvas.getContext(id, attributes);
      if (context) {
        return /** @type {!WebGLRenderingContext} */ (context);
      }
    } catch (e) {
      // pass
    }
  }
  return null;
}

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Any further updates or thoughts on WebGL2?

I think implementing Webgl2 support in a way that allows us to really benefit from it would be a lot of work, and IMO not really worth the energy. I would personally hold my breath for WebGPU on this one 🙂

In MapLibre support for using a webgl2 context was added not too long ago, with a fallback to webgl1. The shaders weren't changed, so they're as they were with webgl1, so it's alone the shift to webgl2 context that solved many issues - and that work was mainly a matter of conditionally setting the extensions. It's also a good stepping stone towards webgpu, because webgl2 allow for some refactoring of the rendering pipeline that can help prepare. Here are the main changes that were made.

At the time of implementation in maplibre webgl2 had 92% browser support, according to caniuse, but it's a ~94% now and might soon reach a level where the fallback won't be needed. It'll take years before webgpu has ubiquitous browser support like that (i.e. the shader language is still a draft), so it might be possible to get some benefits of webgl2 in the meantime and as a result ease the eventual move to webgpu.

See #15136 for a pull request migrating to WebGL 2.

webgl2 had 92% browser support, according to caniuse, but it's a ~94%

Don't confuse browser support with device support. Different browsers will block different older graphics drivers due to security issues. In Chrome and Edge on Windows 10 this may be fixed by changing ANGLE backend from D3D11 to D3D11on12 in about:flags but all graphics performance including 2d may be degraded as a result.

@mike-000 , thanks for pointing that out. As I understand caniuse is browser support, and browser version usage. The impact on the OS or device settings - is there any way to track that, or is that just a hidden number? We can see sometimes that users get errors when they try to create a webgl2 context, for whatever reason, and that might be contributed to some issues with device support issues rather than browser support. Basically, if I understand you correctly, the numbers from caniuse should be seen as a best-case scenario, but the realistic support percentage, accounting for the device issues, is lower, and it's necessary to run tests on my sites to tell exactly how much.

I have two unrelated ex-Windows 7 systems with Intel graphics running Windows 10 which have this issue, which I suspect is not unusual. Intel HD Graphics driver dated 2016 which both Windows and Intel report as being up to date. The flags fix works but significantly degrades performance. Firefox is not affected. Also no problems with ex-Windows 8 system with AMD graphics. All will be retired in 2 years when Windows 10 support ends.

It is overstating the problem to say that all Windows 10 users are unable to use WebGL 2, right?

We also shouldn't confuse Microsoft's commitment to providing security patches for its operating systems with this library's requirements.

It looks like https://web3dsurvey.com/webgl2 is an effort to collect statistics on WebGL 2 support. Currently showing 96.9% for Windows. I haven't checked what goes into that number, but I think there is sense in looking into survey tools like this. Looks like their collector script is included on https://threejs.org/ and a number of other sites.

It is overstating the problem to say that all Windows 10 users are unable to use WebGL 2, right?

Yes, I think it is Chromium based browsers combined with Windows 7 era Intel graphics causing the issue, not the Windows platform, otherwise Firefox would also be affected.