Vector icon elements are not displaying properly

[Botspot]

I have a Raspberry Pi 4 v1.4 and this most recent chromium-browser upgrade (98.0.4758.106-rpt1 armhf) has caused a somewhat odd behavior. It appears that SVG icons are incompletely rendered.

Here's duckduckgo.com: Here's a composition window from outlook.com: Here's YouTube: (notice the YT logo and icons in the list on the right are all missing)

It's worth noting that on older versions of Chromium, DuckDuckGo would occasionally look like that when the browser first launched. But refreshing helped. Now it doesn't.

[Botspot]

More details about my setup:

• I don't have any experimental Chrome flags enabled, either from the command-line or from chrome://flags.
• chrome://gpu looks normal. I can send a screenshot of it if that would help.
• I am using the official 64-bit kernel on 32-bit Raspberry Pi OS. Edit: not anymore. Turning it off made no difference.
• Chrome Incognito windows return the same result, so that should rule out any extensions causing interference.

[XECDesign]

I'm not seeing this. Any hints on how to reproduce it?

[Botspot]

I'm not seeing this. Any hints on how to reproduce it?

I'm not sure. I started a new thread on the Forums. Perhaps a subset of Pi users are also encountering this, in which case we can try to find a common factor.

[Botspot]

Yesterday I was running Chromium in a Xephyr window, and noticed that vector icons were being rendered correctly in there. Turns out chrome://gpu showed all hardware-acceleration was disabled. I was able to reproduce this result outside of Xephyr by launching chromium with this environment variable:

LIBGL_ALWAYS_SOFTWARE=1 chromium-browser

Of course, this disabled all hardware-acceleration, but at least I can browse the web as I did before. This discovery should reduce the number of possibilities.

[Botspot]

Anything I should try, @XECDesign?

[ryanfortner]

Just thought I should mention that I'm not getting any issues running the latest chromium on rpi os 64-bit.

[Botspot]

Just thought I should mention that I'm not getting any issues running the latest chromium on rpi os 64-bit.

Good to know. I'm under the impression that the issue I'm encountering has to do with RPi's custom hardware-acceleration fixes, which may not all be currently present in the RPiOS 64-bit version.

[XECDesign]

Anything I should try, @XECDesign?

Are you seeing this at all on an official clean image (updated through apt) without any other changes?

If not, then you could try to narrow down the difference between the two?

Or, you could you upload a .img of your sd card somewhere (clearing out all the sensitive data beforehand) and send me a link (serge@.com).

If you're seeing it on a clean image and nobody else is, then that would be interesting.

[Botspot]

I just noticed that my Pi4's bootloader was nearly a year out of date!

pi@raspberrypi:~ $ rpi-eeprom-update
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
   CURRENT: Thu 18 Mar 2021 08:54:11 AM UTC (1616057651)
    LATEST: Tue 25 Jan 2022 02:30:41 PM UTC (1643121041)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

This comes as quite a surprise, as I'm using default Raspberry Pi OS Bullseye and upgrade packages on a daily basis. Both the rpi-eeprom and rpi-bootloader packages have been receiving regular upgrades, but they don't appear to have been applied. Is this normal, @XECDesign?

[Botspot]

I was really hoping that would have fixed it. After rebooting, the rendering issue seems to be unchanged. (I did verify that the bootloader was indeed latest 25 Jan 2022 version after rebooting)

At some point I'll try to shrink my installation-image and share it.

[XECDesign]

I just noticed that my Pi4's bootloader was nearly a year out of date!

pi@raspberrypi:~ $ rpi-eeprom-update
*** UPDATE AVAILABLE ***
BOOTLOADER: update available
   CURRENT: Thu 18 Mar 2021 08:54:11 AM UTC (1616057651)
    LATEST: Tue 25 Jan 2022 02:30:41 PM UTC (1643121041)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

This comes as quite a surprise, as I'm using default Raspberry Pi OS Bullseye and upgrade packages on a daily basis. Both the rpi-eeprom and rpi-bootloader packages have been receiving regular upgrades, but they don't appear to have been applied. Is this normal, @XECDesign?

@timg236, is there new logic to determine whether a critical release should be flashed or is something going wrong there?

[Botspot]

I managed to solve the issue.

This was caused by a combination of two things:

• Me having solved an earlier rendering issue with Chromium v92 and adding the --use-gl=desktop flag to the /etc/chromium.d/00-rpi-vars file. I forgot I did this. However, resetting that file to the default value from rpi-chromium-mods actually worsened the graphical appearance. Everything flickered and glitched, and the terminal received hundreds of GLSL errors per second.
• It turns out that this was also caused by something in the ~/.config/chromium folder. Allowing Chromium to generate a fresh config folder removed all issues. Once that was done, I was able to copy Default, Local State, and Avatars from old to new, to regain all passwords and history.

None of this makes much sense. I don't understand why --use-gl=desktop would break, nor why it would worsen the rendering once removed. Even more unintelligible is how something in my chromium config folder caused a rendering issue, when I had no flags or customizations set. The full error was:

[14722:14722:0321/100955.322148:ERROR:shared_context_state.cc(75)] Skia shader compilation error
------------------------
#version 110

uniform vec4 uclamp_S1_c0;
uniform mat3 umatrix_S1;
uniform sampler2D uTextureSampler_0_S1;
varying vec2 vTransformedCoords_2_S0;
void main() {
    vec4 output_S1;
    vec2 _4_inCoord = vTransformedCoords_2_S0;
    vec2 _5_subsetCoord;
    _5_subsetCoord.x = _4_inCoord.x;
    _5_subsetCoord.y = _4_inCoord.y;
    vec2 _6_clampedCoord;
    _6_clampedCoord = clamp(_5_subsetCoord, uclamp_S1_c0.xy, uclamp_S1_c0.zw);
    vec4 _7_textureColor = texture2D(uTextureSampler_0_S1, _6_clampedCoord);
    output_S1 = _7_textureColor;
    {
        gl_FragColor = output_S1;
    }
}

Errors:
0:1(10): error: GLSL 1.10 is not supported. Supported versions are: 1.00 ES, 3.00 ES, and 3.10 ES

In any case, resetting my config folder definitely helped, so I will close this issue.