Transparency in Cylinders in latest Chrome 74

[vividos]

I'm searching for an issue in my Android app that is using CesiumJS where WallGeometry and. Cylinder entities don't render correctly. The geometry and the cylinder gets half transparent colors. Until recently everything worked, and downgrading my app to previous versions also didn't fix the problem, so I figured a Chrome update was the issue. Then I tried the Cone and Cylinders Sandcastle example with the browser, and the half transparent cylinder is rendered incorrectly. See the attached screenshot.

Sandcastle example:
https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/index.html?src=Cylinders%20and%20Cones.html

Browser:
Chrome 74.0.3729.112

Operating System:
Android 8.1

[vividos]

Some more info. Here's the code:
https://github.com/vividos/WhereToFly/blob/master/src/App/Resources/Assets/map/mapView3D.js
in line 891 I'm adding the half transparent cylinder entity, and in 1089 I'm adding the WallGeometry to the scene.

While debugging, apparently Chrome issues some warning messages:

[ERROR:gles2_cmd_decoder.cc(4965)] [.WebGL-0xebb87200]GL ERROR :GL_INVALID_OPERATION : glDrawElementsInstancedANGLE: GL_BLEND with floating-point color attachments requires the EXT_float_blend extension

This error line is repeated many times, until it stops:

"WebGL: too many errors, no more errors will be reported to the console for this context.", source: file:///android_asset/map/ (0)

[mramato]

Thanks for the bug report @vividos! Does anyone with an Android device want to try and reproduce this and see if it's an easy fix? At first glance it looks like we might be missing an extension check and going through the wrong rendering path.

CC @OmarShehata @emackey

[vividos]

I checked with another device running a previous version of Chrome and it works there. Version tested was 73.0.3683.90 with today's Sandcastle page, which I assume is the latest CesiumJS version 1.57.

[vividos]

It's getting more mysterious. I updated to version 74.0.3729.136 of Chrome on both a Samsung Galaxy S9 and an older Google Nexus 5X, and the Sandcastle Cone demo works on the S9, but not on the older Nexus 5X (same screenshot).

How can I help you reproduce this bug, or getting you more infos about this bug or my Nexus 5X device?
Can I prevent the bug by specifying transparency differently? With integer values perhaps?
Thanks!

[OmarShehata]

@vividos thanks for all the additional testing! I am able to reproduce this on my Pixel 3 with Chrome 74.

I think this is an issue of the browser reporting it can support floating point textures when it does not. The EXT_float_blend extension gets enabled implicitly when EXT_color_buffer_float, OES_texture_float, or WEBGL_color_buffer_float are enabled, which Cesium does enable.

Furthermore, if you force the floating point textures to not be used by hardcoding the following 6 variables in Context.js to false:

https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Renderer/Context.js#L283-L290

Then the transparency works as expected on my Pixel 3.

If this is indeed an issue of the browser reporting support without having full support, we could fix this by doing a render check at start time to check if the extension is actually supported (which would slow down start time) or add an option in the Context constructor to disable floating point textures so the developer can disable it themselves in these situations.

[bposselt]

I have a user who is reporting similar behavior on a Windows 7 Dell laptop without a touchscreen, and it's not just cylinders. It's all polygons that lose their fill. Installing the version 75 beta produces the same result.

Editing to mention that it's only him so far; all other users with similar configs are working fine. So maybe there's a hardware component, too?

[craigtong]

I am currently seeing this effect with various Dell laptops running Windows 7 with Chrome 74, including Windows 7 in a VirtualBox VM. This is with an entity with an SVG icon as the billboard and transparency in the fill/stroke.

[OmarShehata]

@craigtong can you confirm if this issue only occurs in Chrome? Can you try IE/Edge/Firefox on those Dell laptops?

I believe this is the same issue reported in this forum thread.

[vividos]

Is there a workaround? Eg. not using float values for transparency, but integer RGBA values? It could I force CesiumJS to use the extension anyway? I'm using the minified version and can't modify the CesiumJS code directly. Thanks!

[OmarShehata]

@vividos CesiumJS is already requesting the extension - the problem is that the browser reports that it can support this extension, but it doesn't, so it ends up not using the fallback path.

You could rebuild the modified source to get a custom minified version with these extensions turned off as I described here #7798 (comment). Otherwise you could try to monkey patch it but it's a little tricky because you'd need to turn this off after the Context is created but before it initializes all the textures.

[vividos]

So maybe it's best to open a ticket in the chromium project then?

[OmarShehata]

Yeah this looks like specifically a Chrome on Windows and Android issue (so far at least). There's some more reports of people experiencing this on the forum:

https://groups.google.com/d/msg/cesium-dev/aMOGTydwgwQ/HgJcRk3IAAAJ

[vividos]

I opened a Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=964208
All: Please comment on the bug if you have more infos to share with the Chromium team. Thanks!

[kainino0x]

There was a spec change in KhronosGroup/WebGL#2779 which requires EXT_float_blend to be requested in order to use float blending. That said, it seems likely that there is indeed a Chrome bug here, since it was working before.

Does Cesium request it? It seems to be attempting to use float blending regardless of whether EXT_float_blend is successfully requested. (On Chrome/Pixel 3, EXT_float_blend is not available, but I guess Cesium still uses it.)

[kainino0x]

I think this is an issue of the browser reporting it can support floating point textures when it does not. The EXT_float_blend extension gets enabled implicitly when EXT_color_buffer_float, OES_texture_float, or WEBGL_color_buffer_float are enabled, which Cesium does enable.

Oh, this explains how it gets enabled. Nonetheless, enabling those things only implicitly enables EXT_float_blend if EXT_float_blend is available, so you still may want to check the availability before using float blending.

[vividos]

I think @OmarShehata can answer this the best. Thanks for your analysis!

[vividos]

So how can we get to a fix for this bug? Is it on CesiumJS side or should chromium fix this? From the discussions I get that EXT_float_blend extension is not supported on many Android devices...

[OmarShehata]

Ah, I didn't realize the spec had changed. Thanks for the explanation @kainino0x .

This is potentially an easy fix on the CesiumJS side, we just have to check if EXT_float_blend is supported. Although it does sound like this will disable this feature for a lot of devices that seem to support it in practice but don't advertise it. Like my laptop with Nvidia Quadro M1200 reports no support for it. And it doesn't seem to have a lot of support on desktop based on https://opengl.gpuinfo.org/listreports.php?extension=GL_EXT_float_blend

@lilleyse does this sound like the right approach here to you too? Do we rely on blending floating point textures for any big features that don't have a fallback?

So I guess the reason it worked before (and works in Firefox) is that the browser simplify didn't check for this and let it try regardless of whether the hardware advertised support for it not.

[lilleyse]

OIT requires floating point texture blending, so the correct thing to do would be to check for EXT_float_blend in OIT.js#L47. EXT_float_blend doesn't seem to be widely recognized though and I'd be afraid of having this check disable OIT for many users.

I think it's best to not change Cesium's behavior yet and wait for a Chrome fix. For those who need to work around this in the meantime, try setting orderIndependentTranslucency to false.

var viewer = new Cesium.Viewer('cesiumContainer', {
    orderIndependentTranslucency : false
});

[mramato]

I think it's best to not change Cesium's behavior yet and wait for a Chrome fix. For those who need to work around this in the meantime, try setting orderIndependentTranslucency to false.

I'm not sure this is the right approach. Cesium should do "the right thing" and request any extensions that we want to use. I think having stuff work by accident is a recipe for a lot of unexplained or hard to track down bugs in the future.

[kainino0x]

We'll see what we can do about our extension-support-detection problem on Android, and maybe it'll be easier for you to make a decision here after that. I think chances are we'll have to fake-enable this extension on Android, since the functionality "just works" (it would be implicitly enabled just like on desktop platforms, but you can still detect EXT_float_blend to check for support). You can star crbug.com/964208 to subscribe to updates on that.

[shrekshao]

FYI, in chrome 74 EXT_float_blend is still implemented as a draft extension (Not listed explicitly by default) But if other related extensions are enabled (e.g. EXT_color_buffer_float as stated) it still gets enabled if there's device support. It goes public in 75 which will be released in about a week.

This could lead to some confusion since you don't see EXT_float_blend getting listed in say webglreport.com for both devices that support EXT_float_blend (PC) and those don't (Android).

I thought the issue might be some devices that have Float32 blending functionality don't list it in supported extension. But testing with a simple webgl test that blends and readpixel on a pixel 3 XL and a samsung galaxy note 5 shows they simply just cannot do Float32 blending at all.

I put the test here: https://github.com/shrekshao/WebGL/blob/ext-float-blend-feature-detect/sdk/tests/conformance2/extensions/ext-float-blend.html
Let me know if you have a device that prints This device has float 32 blending functionality even if EXT_float_blend is not listed and This device doesn't have EXT_float_blend listed at the same time (need a httpserver to run and need query string ?webglVersion=2

Also could it be releated to float 16 bits vs 32 bits? In chrome only Float32 blending is affected EXT_float_blend validation.

[lilleyse]

@shrekshao I get that result on my device. GTX 2070 (driver 418.56), Ubuntu 18.04, Chrome 74.0.3729.131.

This device has float 32 blending functionality even if EXT_float_blend is not listed
This device doesn't have EXT_float_blend listed

[OmarShehata]

Thanks a lot for this test @shrekshao ! I put it up here to make it easier for others to test:

https://float-blend-test.glitch.me/?webglVersion=2

On my laptop with Nvidia Quadro M1200, Windows 10 and Chrome 74.0.3729.157 I get:

This device has float 32 blending functionality even if EXT_float_blend is not listed
This device doesn't have EXT_float_blend listed

On my Pixel 3 with Chrome I correctly get that this device can't do float 32 blending and that the extension isn't listed.

[lilleyse]

On my laptop with Windows 10, AMD Radeon R9 M370X, and Chrome 74.0.3729.157 I also see

This device has float 32 blending functionality even if EXT_float_blend is not listed
This device doesn't have EXT_float_blend listed

[mramato]

On my laptop with Ubuntu 18.04, Intel HD Graphics 630, and Chrome 74.0.3729.157 (Official Build) (64-bit) I also get

This device has float 32 blending functionality even if EXT_float_blend is not listed
This device doesn't have EXT_float_blend listed

[vividos]

On my Nexus 5X device with Chrome version 74.0.3729.157 I get:

This device cannot do float 32 blending
This device doesn't have EXT_float_blend listed

[shrekshao]

~~Ah sorry to mention. You should use canary.~~ ~~In 74 ext float blend is in draft mode. So it's expected it's not listed~~ NVM I do see This device has float 32 blending functionality even if EXT_float_blend is not listed This device doesn't have EXT_float_blend listed. in chrome 73 of my pixel 3 xl

…

On Tue, May 21, 2019, 07:08 vividos ***@***.***> wrote: On my Nexus 5X device with Chrome version 74.0.3729.157 I get: This device cannot do float 32 blending This device doesn't have EXT_float_blend listed — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7798>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGMNLA2262OFC3E3RPCWJLPWP67PANCNFSM4HJSXNQA> .

[lilleyse]

@shrekshao on my windows machine with Canary:

This device has float 32 blending functionality even if EXT_float_blend is not listed
This device has EXT_float_blend listed

[kainino0x]

On Pixel 3, chrome 71, I see:
This device has float 32 blending functionality even if EXT_float_blend is not listed

So apparently this chip does indeed support it. (Of course, it is disabled on Canary, so float blending doesn't work.)

[kainino0x]

edit: that's chrome 71, not 74.

[vividos]

I also tested with Chrome canary, version 76.0.3801.0, on my Nexus 5X, with the following results:

This device cannot do float 32 blending
This device doesn't have EXT_float_blend listed

So it's the same as with the 74 versions...

[OmarShehata]

@vividos I believe this result is correct. Since the browser there reports that the extension is not supported, and the device indeed does not support it, then CesiumJS can fallback to not using float textures.

The problem is the cases when the device can support it but the browser reports that it doesn't. The other issue is figuring out if Firefox exposes this check in the same way, or if we have to only rely on this check in Chrome.

[vividos]

I'm confused. Soo what's the solution now? With Chrome 73 the primitives with transparency worked fine on my device, whereas with 74 it fails.

[shrekshao]

I'm working on a patch in chromium to detect if there's EXT_float_blend capability by really drawing something on a float32 texture with blending onlaunch. The patched chromium already resumed blending in the cesium cone and cylinder demo correctly on pixel 3. Just some finishing work to get it landed. You could follow https://bugs.chromium.org/p/chromium/issues/detail?id=964208 for updates.

[kainino0x]

In the meantime, you can still use the workaround above: #7798 (comment)

[vividos]

@shrekshao Thanks for the info
@kainino0x I'm using that flag and it works on my Nexus 5X now. Thanks!

[vividos]

The cylinders and cones demo works again in Chrome Canary 77.0.3820.5, so I guess it will be also working in the next Chrome version. I'm closing this issue.

[cesium-concierge]

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/d/msg/cesium-dev/aMOGTydwgwQ/j_8U3me8AQAJ
https://groups.google.com/d/msg/cesium-dev/aMOGTydwgwQ/HgJcRk3IAAAJ

If this issue affects any of these threads, please post a comment like the following:

The issue at #7798 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

[edejin]

Same issue
Ubuntu xenial
Chrome Version 76.0.3809.100 (Official Build) (64-bit)
But Chrome Version 77.0.3865.42 (Official Build) beta (64-bit) works fine

[vividos]

Today Chrome 77.0.3865.73 was installed in my device, and this version fixes the rendering problem - only 3 chrome versions later ;-)