Have a lot of WebGL WARNINGs in Chrome and Firefox consoles.

[vadym1930]

JS HERE maps version 3.1.12

From Chrome

From Firefox

Does someone face the same?

With that said some labels on the map looks like that

[dbacarel]

Hi @vadym1930, thanks for reporting the issue. Can you also provide some additional information about your environment?

Example:

• browsers version
• OS
• output of https://webglreport.com/
• possibly graphic card

Thanks!
Daniele

[vadym1930]

Thanks for the response. It's known that it's not my machine-related. I guess I did something wrong while working with API. I have a clue — need to make a couple of tests.
Gonne let you know in a few days.

[vadym1930]

Okay, I was attaching the scripts wrong way so after correcting myself and doing it the way docs recommended the issue with artifacts on the map has gone. So labels are nice now. I still have a lot of similar warnings though
46 [.WebGL-0x7fc8da859400]RENDER WARNING: there is no texture bound to the unit 0

What is noticing that I have a lot of map instances on the same page and maps are hidden by default and mentioned warning starting popups right after the second map was opened (its kind of card collapsed layout) and the same behavior repeating with the every next opened map so new bunch of warning adding again and again.

While the labels are good I can live with that. But if you guys can figure out and get rid of the warnings that would be great.

I might create the codepen or similar with a few collapsed maps just to prove it exists. Let me know if such a thing could be useful to track this down.

[ankit-vaghela]

Same issue I have with here map version 3.1. Even in your sample code it is not working. check below link.
https://heremaps.github.io/maps-api-for-javascript-examples/polyline-on-the-map/demo.html

[oleksmarkh]

@vadym1930, could you please create and share a CodePen if there are still "texture bound" warnings. We'll reopen the issue and try to track it down then.

@ankit-vaghela, the shader error you've mentioned is probably hardware-related. I'd suggest we use #72 to scope it.