heatmap layer shows only one color from colorRange

[UttamRahane]

Description

Repro Steps

const heatMap_layer = new HeatmapLayer({
data: this.geoJson.features,
id: 'heatmp-layer',
opacity: 0.6,
getPosition: d => d.geometry.coordinates,
getWeight: d => d.properties['Max Capacity'],
colorFormat: 'RGBA',
colorRange: [[1, 152, 189, 255], [73, 227, 206, 255], [216, 254, 181, 255], [254, 237, 177, 255],[254, 173, 84, 255],[209, 55, 78, 255]],
intensity: 1,
radiusPixels: 80,
threshold: 0.9
});

-->

Environment (please complete the following information):

• Framework Version: [e.g. deck.gl 7.2.3]
• Browser Version: [e.g. Chrome 71.0]
• OS: [e.g. Mac OS X 10.4]

[1chandu]

Can you share result image? Which of the colors in colorRange are used? Also try adjusting radiusPixels and using default colorRange.

[UttamRahane]

expected result should be something like -

There should be different color according to the value of 'Max capacity'

[UttamRahane]

using default colorRange, it shows only yellow color. that means it shows only first color.

[1chandu]

Based on your image it seems all the pixels are falling into lower end of heat map range. Locally I am not able to reproduce this problem, can you share your system details? Browser, GPU, OS (complete the environment section in description) ? Also can you minimize the issue to few data samples and share that data here?

[SterlingMcCall]

I am seeing this same issue with deck.gl v7.2.3 in Windows. It happens in both Chrome and Edge. It works as expected in Chrome on linux.

[UttamRahane]

Browser : Chrome Version 76.0.3809.132
GPU: Intel(R) UHD Graphics 620
OS: windows 10
I'm trying to implement it using Vue
you can use geojson format and take value from properties

[SterlingMcCall]

This bug occurs on Windows when hardware acceleration is enabled regardless of graphics chipsets. I tested both Nvidia and Intel graphics in Chrome and Edge 18 (non-chromium Edge). To prove the issue, go to chrome://settings/system and disable the option titled "Use hardware acceleration when available" and the heatmap will behave normally.

Issue still present as of deck.gl@7.2.6 and deck.gl@7.3.0-beta.4.

I do not know if this is a Chrome bug or a deck.gl bug, but it is definitely a bug.

[SterlingMcCall]

To reproduce this bug, just look at the heatmap demo in the documentation on a Windows machine with hardware acceleration enabled.

[tsherif]

@UttamRahane @SterlingMcCall can you load up this page on your systems and let us know the results: https://tsherif.github.io/webgl2-render-target-test/

It should look like this:

[UttamRahane]

The document page on chrome browser looks like:

On Edge:

@tsherif your page gives the same output as you expect but on chrome.
On Edge it gives a message

This example requires WebGL 2 which is unavailable on this system.

[SterlingMcCall]

@UttamRahane @tsherif I misspoke about Edge. As would be expected, Edge does not work at all due to lack of WebGL2 support. I tried firefox on windows and observe the same issue with the same color everywhere, but disabling hardware acceleration in the firefox settings did not fix the issue like it did in Chrome.

@tsherif
Testing https://tsherif.github.io/webgl2-render-target-test/ on a Windows 10 machine with Intel HD graphics:

• Firefox with hardware acceleration - same as your screenshot
• Firefox without hardware acceleration - same as your screenshot
• Chrome with hardware acceleration - same as your screenshot
• Chrome without hardware acceleration
  • red, black, black, black
  • red, red, red, red
  • red, red, red, red
• Edge 18 - "This example requires WebGL 2 which is unavailable on this system."

[SterlingMcCall]

On the same windows 10 machine with Intel HD graphics on Edge 18 with deck.gl@7.3.0-beta.4 the heatmap displays this same visual issue seen on Chrome and Firefox.

[1chandu]

@SterlingMcCall , to summarize, when using deck.gl@7.3.0-beta.4, it is specific Windows only, and happens on all browsers (Edge, Chrome and Firefox) ? Also the issue is, it shows first color only from the colorRange and there are no crashes in console?

[SterlingMcCall]

@1chandu

to summarize, when using deck.gl@7.3.0-beta.4, it is specific Windows only, and happens on all browsers (Edge, Chrome and Firefox) ? Also the issue is, it shows first color only from the colorRange and there are no crashes in console?

Correct. That would be an mostly accurate summary. I would add the following:

• WebGL 1.0 support was added in deck.gl@7.3.0-beta.4 allowing the bug to be seen in Edge, but previous versions of deck.gl also experience the same bug on WebGL 2.0 browsers. This would seem to rule out differences between 1.0 and 2.0.
• Not only is the first color from the colorRange picked, the edges do not fade smoothly. The threshold property has no effect and does not soften around the edges as you would expect.
• On Chrome, disabling hardware acceleration "fixes" the issue. Disabling hardware acceleration in Firefox has no effect. I could not figure out how to disable hardware acceleration in Edge if it is even possible to do so.
• The bug is observed in Windows machines running either Intel HD or Nvidia graphics. I could not test on AMD hardware.

Could it be a Windows bug?

[1chandu]

@SterlingMcCall , thanks for the details.

We are also seeing a crash in iOS due to unsupported WebGL feature (render to float textures), I am working on a fix to fallback to unsigned byte textures (with low precession), given what you are seeing is not a crash but rendering artifact, that could be a different issue specific to windows browsers. I will take a look.

On Chrome, disabling hardware acceleration fixes the issue. Disabling hardware acceleration in Firefox has no effect. I was not able to determine if it is possible to disable hardware acceleration in Edge.

disabling hardware acceleration, uses software rendering (doesn't use GPU), so not limited by WebGL extension support. Firefox's software rendering might have bugs.

[tsherif]

@1chandu The bug indeed appears to be in ANGLE. The easiest way I found to test is in Firefox, go to about:config and set disable-angle to true. The heatmap layer rendered fine for me afterwards. I tried to disable ANGLE in Chrome as well, but the browser became unresponsive so I couldn't test.

If we narrow down the issue, we can report a bug here: https://bugs.chromium.org/p/angleproject/issues/list

[1chandu]

@tsherif , awesome !! I will dig more into this ..

[1chandu]

@SterlingMcCall @UttamRahane
Can you try using deck.gl 7.3.0-beta.6, this includes few fixes for WebGL1 support.
Also can you try following demos:

1. maxWeightLog : https://codepen.io/1chandu1/pen/rNBRqRz
   => in console I am logging max weight, please copy paste the log
2. custom maxWeight: https://codepen.io/1chandu1/pen/BaBbGxQ
   => use the maxWeight slider and see if you able to see full color spectrum instead of single color, provide screen shots for like when maxWeight is 100 and 900.

Thanks.

[SterlingMcCall]

Switching to deck.gl@7.3.0-beta.6 has no impact on any browser on windows. The bug is still present.

demo 1 console output:

util.js:329 This page appears to be missing CSS declarations for Mapbox GL JS, which may cause the map to display incorrectly. Please ensure your page includes mapbox-gl.css, as described in https://www.mapbox.com/mapbox-gl-js/api/.
w @ util.js:329
r._detectMissingCSS @ map.js:1500
r._setupContainer @ map.js:1513
r @ map.js:358
_create @ dist.min.js:6
_initialize @ dist.min.js:6
l @ dist.min.js:6
o @ dist.min.js:11
(anonymous) @ pen.js:2
pen.js:36 maxWeight: 0,0,0,0
pen.js:36 maxWeight: 0,0,0,0
pen.js:36 maxWeight: 0,0,0,0

demo 2:

It would seem that your custom heatmap layer fixes/bypasses the issue. Awesome work!

[1chandu]

@SterlingMcCall , thanks for the details, this isolates the issue domain calculation, digging into it ...

[1chandu]

Problem root caused to ANGLE not supporting rendering to 1X1 textures, workaround (specification of custom domain) will be part of 7.3 release (ETA 09/27).

[SterlingMcCall]

@1chandu Awesome! Has a related ticket been opened on the ANGLE repo?

[1chandu]

@1chandu Awesome! Has a related ticket been opened on the ANGLE repo?

Yes, link : https://bugs.chromium.org/p/angleproject/issues/detail?id=3941

[1chandu]

@SterlingMcCall @UttamRahane , please try deck.gl '7.3.0-beta.9 ', and when using windows, set colorDomain props to [0, maxValue], where maxValue is big enough to show all hot spots. For website demo we are using 30000 for maxValue. Once ANGLE issue fixed this value will be auto calculated.

[SterlingMcCall]

@1chandu Because it was available, I used the 7.3.0 release not the beta. Specifying the colorDomain does fix the issue, however it is not practical for dynamic datasets. In my use case, the maximum density of the data is not known so I am not able to choose an upper domain that works 100% of the time.

From my very basic understanding of the algorithm, you recursively decrease the size of a texture until you end up with a 1x1 texture meeting some criteria, correct? Would it be possible to simply add a parameter to instead stop the algorithm at a 2x2 texture in the mean time?

Regardless, this effort and current work around is much appreciated.

[1chandu]

colorDomain is not the solution, we added it more like a feature for use cases where you want to control the domain to color mapping.

From my very basic understanding of the algorithm, you recursively decrease the size of a texture until you end up with a 1x1 texture meeting some criteria, correct? Would it be possible to simply add a parameter to instead stop the algorithm at a 2x2 texture in the mean time?

I am not rendering to decreasing sizes, instead directly render to 1X1. I am hoping the ANGLE issue is resolved soon, and this shouldn't be a problem.

[SterlingMcCall]

I am hoping the ANGLE issue is resolved soon, and this shouldn't be a problem.

While I agree that would be the optimal solution, over half of Edge users are on a versions of Windows over a year old, and since Edge versions are tied to the Windows build, it could be a year or two after the ANGLE bug is fixed before a majority of Edge users will be able to take advantage of the dynamic domain calculation.

Is there any way to implement a workaround? Or is this bug too inherent to the domain calculation to do it differently?

[1chandu]

Stay tuned, will update here soon...

[1chandu]

@SterlingMcCall , added workaround for ANGLE issue in deck.gl 7.3.2, please give it a try, you don't have to set colorDomain, max value will be auto calculated.

[SterlingMcCall]

@1chandu The workaround appears to be working correctly. Thank you!

[1chandu]

Thanks for confirming, closing !!