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:
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.
