nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Route not displayed after update to chromium 145/146 on Raspberry Pi 4

Alamos

Hello,

after updating the raspberry pi chromium to version 146, the route calculated on the map is not visible any more.

I dont see an error in the browser log.

To be sure that the my app is not the cause of the issue, i also tried it on the example page https://developers.arcgis.com/javascript/latest/sample-code/directions-routelayer/

There is no route visible on chromium 145 (and chromium 146), too.

On chromium 142 it has been working without any issues.

WebGL is hardware accelerated according chrome://gpu list, WebGPU is disabled.

The maps are displayed without problems.

Do you have an idea?

Thanks!

Trouver plus de publications taguées avec

Accepted answers

All comments

AndyGup

@Alamos with Chrome 146, can you see the graphics in this sample? https://developers.arcgis.com/javascript/latest/sample-code/intro-graphics/.

Alamos

no, i cannot see them as well.

mgeorge

@Alamos if you go to https://webglreport.com/?v=2 does anything seem off? You might need to make a bug report on the chromium project (https://issues.chromium.org/) if this is a regression in the latest version of chrome.

Alamos

It seems that everything is set up right.

Bild (2).png

MaxKirschling

I just wanted to chime in and say I am experiencing the exact same issue with the exact same hardware/software combo. The only thing I have to add is that when I view the route-layer sample page (https://developers.arcgis.com/javascript/latest/sample-code/directions-routelayer/), the full route does not display (same as OP) but when I hover over a specific step of the route it will display that specific route segment.

@Alamos, did you ever post the bug on issues.chromium.org? If so, could you provide the bug ID#? I would like to follow it for any updates from

MaxKirschling

I wanted to share a workaround that I figured out, although it comes with a cost. For reference, this was used on a Raspberry Pi 5 running PiSignage. Based on the solution I discovered, the problem seems to be with OpenGL ES (GLES), as the routing layer was correctly calculating the route but wouldn't actually draw it.

My Workaround

The solution was to force Chromium to utilize swiftshader instead of gles. This change resulted in the routing layer drawing on screen, but at the cost of some performance (as swiftshader is a software based renderer that utilizes the CPU rather than any onboard GPU).

Using a terminal on the Pi device, or via an SSH connection, I created a file:

sudo nano /etc/chromium.d/01-pisignage

and added a single line:

CHROMIUM_FLAGS="--use-angle=swiftshader --enable-unsafe-swiftshader"

Because we are using PiSignage, there were other files on the device that were also injecting (conflicting) flags to the Chromium startup. I also had to edit the files located at:

/etc/alternatives/gnome-www-browser
/etc/alternatives/x-www-browser

By searching for "--use-angle=", I was able to replace the text

--use-angles=gles

with

--use-angles=swiftshader --enable-unsafe-swiftshader

After that switch, everything worked, although there is a noticeable drop in response-time. Hopefully this will help someone out there with a similar issue, at least until the devs at Esri and/or Chromium can squash this bug.

Alamos

Hello,

thanks for the workaround.

Our customer opened an offical bug / ticket on Esri and I think they are going to investigate this issue. They could already reproduce it by theirselves so I am optimistic that we get a solution or fix soon.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.