1645800 - WEBGL GL_EXT_draw_buffers broken

Status: UNCONFIRMED

(Core :: Graphics: CanvasWebGL, defect, P2)

Description

[tinyrsid]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36

Steps to reproduce:

Steps to reproduce the problem:

1. use a Firefox 66.0 or an old Chrome version from 2017 (for correct output)
2. open my page: http://www.wothke.ch/269life/
3. compare to the broken results that you get when opening the same page in any Firefox version more recent than 67 (see details below)

Actual results:

The above web page depends on the WEBGL GL_EXT_draw_buffers feature and the original semantics that additional color attachments can remain UNUSED! i.e. fragment shaders will always write to gl_fragColor or gl_fragData[0] but NOT ALL used shaders will write to all the provided additional attachments (i.e. gl_fragData[1], gl_fragData[2], etc)

The benefit of allowing unused color attachments should be rather obvious: In the example at hand THREE.js is used as a base and all the fragment shaders provided in that respective library version exclusively use gl_fragColor (no additional color attachments at all). Without the option to allow "unused additional attachments" all those shaders would be completely useless as soon as a GL_EXT_draw_buffers based shader is added to a scene (like the shader that I am using for the "glowing"/"god rays" causing texts: it renders an additional marker into an attachment that nobody but the respective postprocessing Pass cares about and it makes perfect sense that shaders that use a different number of additional attachments can be used within the same scene!)

What went wrong?
It seems someone decided to unnecessarily make a non-backward compatible change in the existing GL_EXT_draw_buffers related API thus breaking existing application code for no good reason! Luckily I am not australian or I'd have do call it "dangerous levels of egregious dumbfuckery":

It seems that Firefox's changed GL_EXT_draw_buffers implementation (probably changed in version 67) now demands that all configured attachments must always be written to by ALL used fragment shaders. I guess that this is the "reason" why my 3 years old example page now fails misably in Firefox with hundreds of silly

"Error: WebGL warning: drawElements: Program has no frag output at location 1, but destination draw buffer has an attached image. three-plus.min.js:5:30251
Error: WebGL warning: drawArrays: Program has no frag output at location 1, but destination draw buffer has an attached image."

error messages in the console.

Expected results:

With regard to the example web-page:

1. some seconds into the fractal animation a small white text overlay should appear (more respective overlays appear throughout the demo; see https://youtu.be/1eCm5E8O5cI?t=48 ) => these overlays completely fail in Firefox 67ff (not shown at all)
2. further into the animation a white "269life" logo should appear in the center of the screen (see https://youtu.be/1eCm5E8O5cI?t=106 ) -> the respective logo should use a "glow" effect and cause a "god rays" effect on the surounding background scene => no longer works in the current Firefox version
3. about 7 minutes into the animation (see https://youtu.be/1eCm5E8O5cI?t=467 multiple effects completely fail in Firefox): a) There should be a "Revison" logo shown "on the ground" (bottom right corner of the above video recording); b) there should be yellow "confetti" raining from the sky; c) there should be a purple "northern light" pattern on the horizon; d) the vertical texts that hang from the sky should use the "glow" effect and cause the "god rays" effect on the background (like "269life" logo in the earlier scene) => all of these are broken in Firefox

The semantics of the GL_EXT_draw_buffers API should be restored in a backward compatible manner: The respective functionality works correctly in Firefox 66 (and probably earlier versions) and it had worked correctly in Chrome as early as 2017!

To demand that all color attachments that must always be written to by all shaders is about as silly as if one demanded that C++ methods must always use all declared method parameters. IT MAKES NO SENSE!

This feature worked fine and has been used for years and there is NO good reason to break ppls application code. This unwarranted non-backward-compatible change should immediately be reverted and responsible ppl should be given a free lecture about the meaning of "backward compatibility"!

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[tinyrsid]

I had to update the youtube recordings and above URLs should be replaced by:
https://youtu.be/InwEtKS59eI?t=48
https://youtu.be/InwEtKS59eI?t=106
https://youtu.be/InwEtKS59eI?t=463

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[tinyrsid]

I see.. you've been ignoring this bug for more that 2 years now.. f**k you. from now on I'll not waste my time reporting bugs in your POS brower and switch to a different supplier.