Can there be a "Known Issues or Bugs" Section to the Forum?

Site Feedback
, , ,
1

Is it possible to have a known bugs section to the forum?
Recently I had a display issue that I though was in my implementation however the case is that it is a known issue with MacOS chromium based browsers and meshes with more than 64K vertices, but not on WebKit browsers.

Affected MacOS Versions Browsers:

  • Chrome
  • Brave
  • Edge
  • Opera

Unaffected MacOS Browsers

  • Safari
  • Firefox
  • DuckDuckGo

After days of searching:
Chromium Issues has this Issue:
[Chromium](https://WEBGL and Chromium Browsers on MacOS)

2

Issues · mrdoob/three.js · GitHub :thinking:

If its confirmed to be a browser issue it’s best to also file a report with the respective provider(s)

1 Like
3

I think the essence of the proposal is not to report bugs, but to collect a list of issue. Three.js users that experience a problem may look up in this list and check whether their issue is a known problem or not. This might save a lot of efforts and frustration.

2 Likes
4

I second the motion, it would be definitely helpful.
I’m also struggling with a similar issue atm, but it’s more like a Mac vs Windows issue, and it might be a known one, I just can’t seem to find it anywhere.

1 Like
5

Correct. just a place to have known issues if they belong to another provider and known bugs if they belong to threejs.

1 Like
6

Copy… I reported it to Chromiun its been an issue since 2019… but not with Webkit.

1 Like
7

Every GPU manufacturer has their own drivers.

Intel and qualcomm drivers are notoriously buggy. Intel has been getting better over the years. ATI’s drivers are pretty good… NVidia drivers are the most compatible, although almost to the opposite extreme in that they will proactively put fixes in their drivers to “fix” issues with devs doing unsupported or underspecified operations.

It would be nice if there was a database of “these things are broken” but creating such an artifact is a Ton of work, and these bugs get fixed over time, and new ones crop up, so its a never ending process.

You can grind your fingers down trying to work around issues like this, or you can just check the GPU string and blacklist them from your app, and show them a mp4 instead with a label like “Driver XYZ has a known issue and is not supported by this app.” and move on with your life.
The more hoops you go through to work around the issues, the more you relieve the pressure on manufacturers to fix their drivers.
I know this isn’t super helpful advice, but I just want to give some perspective.

Here’s a code snippet which may tell you what driver is actually in play while your app is running, and perhaps can be something to key different behaviors under different circumstances.

function getWebGLRendererInfo() {
    // Create a canvas element to initialize WebGL context
    var canvas = document.createElement('canvas');
    var gl = canvas.getContext('webgl') || canvas.getContext('experimental-webgl');

    if (!gl) {
        console.log('WebGL not supported');
        return;
    }

    // Access the WEBGL_debug_renderer_info extension
    var debugInfo = gl.getExtension('WEBGL_debug_renderer_info');

    // If the extension is available, extract the GPU and driver information
    if (debugInfo) {
        var vendor = gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL);
        var renderer = gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL);
        console.log('GPU Vendor: ', vendor);
        console.log('GPU Renderer: ', renderer);
    } else {
        console.log('Unable to access WebGL debug renderer info.');
    }
}

getWebGLRendererInfo();
3 Likes
8

the github api is a way to get a list of all the issues of a given repo, the result can be filtered and organized however you wish really, I personally like ven diagrams. I would also say that having a source of truth to all existing issues as well as closed outdated ones should ideally all be kept in one place for devs to look into and fix, github issues is the ideal way of managing this and attaining this data through the provided api is the only real way of clinically consuming this real time data, otherwise as @manthrax has outlined, this will quickly become a never ending nightmare project to maintain…

EDIT:

This is also achievable through using the github api as you could get all issues tagged webgl / three js from all the necessary providers repos and create an automated framework to categorise and cross reference issues from all sources, again, without an appropriate framework in place that will heavily automate this, it seems like a burden for what it’s worth…

2 Likes