SVG rendering fragmented on Torizon using torizon/weston-vivante:2.7.2 and torizon/chromium:2.6.0 containers

bgo · July 22, 2022, 8:34am

Hi all!

We are currently experiencing some rendering issues with SVG graphics. Our setup is as follows:

Verdin iMX8MP Q 4 GB WB IT
Dahlia V1.1A
hp display connected via HDMI
TorizonCore 5.6.0+build.13
customized SplashScreen (company logo)
docker containers torizon/weston-vivante:2.7.2 and torizon/arm64v8-chromium:2.6.0

SVG images are heavily fragmented as can be seen in the following screenshot (taken with VNCViewer and shows the rendered result from commanding chromium to navigate to svgrepo.com):

Since I am not sure if we actually made something wrong within our configuration I would like to ask if this is an actual issue with the container image or just something on our side. The issue might somehow be related to the torizon/arm64v8-chromium:2.6.0 image since the SVG rendering is fine in older versions of the container image (e.g. torizon/arm64v8-chromium:2.5). We would really like to make use of the added HW acceleration in the 2.6.0 chromium image.

Our docker-compose.yml looks as follows:

version: "2.4"

services:

    kiosk:

        container_name: Kiosk

        image: torizon/arm64v8-chromium:2.6.0
        #image: torizon/arm64v8-chromium:2.5

        restart: always

        command: https://www.svgrepo.com/

        depends_on:
            weston:
                condition: service_started

        device_cgroup_rules:
            - c 199:* rmw
            - c 226:* rmw

        environment:
           - MACHINE

        security_opt:
            - seccomp:unconfined

        shm_size: 256mb

        volumes:
         - /tmp:/tmp
         - /var/run/dbus:/var/run/dbus
         - /dev/dri:/dev/dri
         - /dev/galcore:/dev/galcore

        network_mode: host

    weston:

        container_name: Weston

        cap_add:
        - CAP_SYS_TTY_CONFIG

        device_cgroup_rules:
        - c 4:* rmw
        - c 13:* rmw
        - c 199:* rmw
        - c 226:* rmw

        environment:
        - ACCEPT_FSL_EULA=1
        #- ENABLE_VNC=1

        image: torizon/weston-vivante:2.7.2

        platform: linux/arm64

        network_mode: host

        restart: always

        volumes:
            - /tmp:/tmp
            - /dev:/dev
            - /run/udev:/run/udev

The screen resolution is 1920x1080:

Weston    | [07:56:22.957] Output HDMI-A-1 (crtc 33) video modes:
Weston    |                1920x1080@60.0, current, 148.5 MHz

Best regards

lucas_a.tx · July 22, 2022, 5:56pm

Hi @bgo ,

We were able to reproduce your result on our side with the same Verdin SoM and Dahlia model as yours. We used your Docker Compose yaml file for the tests and we tested on a vanilla TorizonCore 5.6.0 as well as the latest 5.7.0 nightly release.

From our initial findings this looks like an issue with our container image, possibly affecting other iMX8 modules with TorizonCore, as the problem also happened on a Colibri iMX8X during our tests.

We’re currently investigating possible causes for this strange behavior. Thank you for reporting this!

In the meantime, could you see if this problem persists using Cog instead of Chromium: Web Browser / Kiosk Mode with TorizonCore | Toradex Developer Center? From our tests the SVG graphics were rendered properly with Cog and it supports hardware acceleration, so it could be a workaround.

Let me know if this helps you.

Best regards,
Lucas Akira

bgo · July 25, 2022, 6:39am

Hi @lucas_a.tx

thank you for investigating!
I followed your instructions using Cog and the SVG graphics are being rendered as expected - thank you for the workaround! We will use it and wait for the next update on your Chromium container

Best regards

gclaudino.tx · July 25, 2022, 12:45pm

Hi @bgo, thanks a lot for the update!

We’ll come back to you once we have any news for you to use Chromium.

Best regards,

bgo · July 25, 2022, 1:40pm

Hi @gclaudino.tx , thank you - any news on your chromium container is much appreciated! Can you estimate a time schedule for it?
Best regards,

gclaudino.tx · July 25, 2022, 1:56pm

Hi @bgo,

I can’t provide you with a timeframe as of today. However, I can assure you that the internal tickets have been created and the team is aware of this problem.

bgo · July 25, 2022, 2:13pm

Hi @gclaudino.tx , thank you! I will look forward for any news

henrique.tx · August 29, 2022, 1:09pm

Hi @bgo !

Unfortunately, we still are waiting for news about the Chromium issue. Thanks for your patience.

Best regards,

kevin.tx · November 8, 2022, 4:27pm

Hi @bgo ,

Hope you are doing well. I made this topic private, so we can share information a bit better.

I am gathering some information, about the status of this issue as it is still unanswered.

How blocking is that issue for you?
Did you find a workaround for it that currently works for you?

I will also ask internally about a detailed status on that ticket in the meantime.

Have a great day.

Best Regards
Kevin

bgo · November 8, 2022, 4:40pm

Hi @kevin.tx ,

I am fine, thank you! And I hope you are doing fine too!

We can keep on working as this is currently only an issue in prototype development on one device. The other prototype devices use 32bit without GPU. Although we would really like to make use of the arm64 respective arm/v8 with GPU acceleration enabled.

Yes. In the current phase of prototyping we are using different devices from different manufacturers. We already decided to upgrade to Apalis iMX8 because it shows the best performance when hardware acceleration is enabled - except for aforementioned fragmentations on SVG rendering. Fun fact: placing a custom animated SVG directly into the Blazer Apps HTML is getting rendered perfectly fine!

I may be able to have a look into this issue next month and find a workaround for our smaller SVG icons.

Have a great day too!

Best regards

kevin.tx · November 10, 2022, 2:09pm

Hi @bgo ,

Thank you for the update.

I understand.

Great!

Interessting, I’ll forward that to the team.

We are working on providing you with a solution. I’ll poke the dedicated team about that issue and I will keep you updated on the progress.

Thanks again.

EDIT:
After some initial discussion, we found this link. This might be a workaround for your smaller SVG’s.

Apparently using the --disable-gpu-rasterization flag helps with the fragmented SVG rendering.

Have a great day.

Best Regards
Kevin

bgo · November 22, 2022, 7:42am

Hi @kevin.tx

Thank you very much! Disabling the rasterization resolves the problem.
For using it in a docker-compose.yaml I managed to find a default-flags file for chromium. So I copied that file to /etc/chromium.d/default-flags, changed the lines for GPU rasterization from

# Enable GPU rasterization.
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-gpu-rasterization"

to:

# Disable GPU rasterization.
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disable-gpu-rasterization"

to disable the GPU rasterization by default. The complete file now looks as follows:

# A set of command line flags that we want to set by default.

# Do not hide any extensions in the about:extensions dialog
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --show-component-extension-options"

# Disable GPU rasterization.
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disable-gpu-rasterization"

# Don't display any warnings about not being the default browser
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --no-default-browser-check"

# Disable pinging
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disable-pings"

# Disable the builtin media router (bug #833477)
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --media-router=0"

And finally I mounted this file into the chromium container:

[...]
    Kiosk:
        container_name: Kiosk
        image: torizon/arm64v8-chromium:2.7
        platform: linux/arm64
        restart: always
        command: http://localhost:5000
        depends_on:
            Weston:
                condition: service_started
            MyApp:
                condition: service_healthy
        device_cgroup_rules:
            - c 226:* rmw
            - c 199:* rmw
        environment:
            MACHINE: null
        security_opt:
            - seccomp:unconfined
        shm_size: 256mb
        volumes:
         - /tmp:/tmp
         - /var/run/dbus:/var/run/dbus
         - /dev/dri:/dev/dri
         - /dev/galcore:/dev/galcore
         - /etc/chromium.d/default-flags:/etc/chromium.d/default-flags
        network_mode: host

This is the way. Well, at least for us. I am always open for a better and more elegant solution.

Best regards

henrique.tx · November 22, 2022, 12:08pm

Hi @bgo !

It is great that you made it work!

Also, you gave great feedback on how to do it

Could we set this thread to be public visible?

Your solution would certainly help other Community users

Best regards,

bgo · November 22, 2022, 1:01pm

Hi @henrique.tx
Sure. Helpful info should be public visible and if you feel like this would be of help to anybody, then please do!
Best regards,