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

Technical Support
, ,
10
11
12
13
14
15
16

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

17

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

18

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

3 Likes
19

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

20

Hi @bgo !

It is great that you made it work!

Also, you gave great feedback on how to do it :smiley:

Could we set this thread to be public visible?

Your solution would certainly help other Community users :slight_smile:

Best regards,

1 Like
21

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,

2 Likes
22

Hi @bgo ,

Thank you we’ll make it public.

Please let us know if we can support you in any other way.

Best Regards
Kevin

1 Like
23
24

Hi @kevin.tx ,

Hope you are doing well!
Sorry to bother you again - I just wanted to check up if there are any plans on updating the torizon/chromium? We set our target architecture for the Apalis iMX8QM (currently using an Ixora Carrier Board, but will swap it with a customized carrier board soon). And we would like to make full use of the hardware acceleration including GPU rasterization. The currently available image for chromium is still Version 100, and I was wondering if there is a way to upgrade it - in case there is no updated container image planned soon.

Best regards

25

Hi @bgo ,

I am doing well. Hope you are too? Sorry for my late reply. Most of my team are attending the Embedded World which makes the response time a bit longer.

No worries, you’re not bothering me.
So, for TorizonCore 5: the supported container version is based on Debian Bullseye. We have no plans to update the container to a newer release.
For TorizonCore 6: the supported container version is based on Debian Bookworm. We are working on building a newer version of Chromium.

The repository for the Debian package is closed source. So it won’t be available straight away. Alternatively, we can share it under NDA and you could try to rebuild it yourself. Which is as I heard not such a trivial task.

Have a great day!

Best Regards
Kevin

26

Hi @kevin.tx ,

no worries, thanks for your reply!
I will wait for the TorizonCore 6 update as this should bring a production ready release for the Apalis iMX8QM anyways - same applies for the Chromium. As I understand, we will then change all containers to Debian Bookworm based ones?

I would really like to try rebuild one by myself, but it will have to wait for another time.
Thanks again, and have a great day too!

Best wishes

27

Hi @bgo ,

Correct! We have the following structure:

  • Debian Buster: containers for early TorizonCore 5. Our Debian containers for Torizon use the tag 1 for them.
  • Debian Bullseye: containers for TorizonCore 5 LTS. Our Debian containers for Torizon use the tag 2 for them.
  • Debian Bookworm: containers for TorizonCore 6, not officially released yet. Our Debian containers for Torizon use the tag 3 for them.

For extra versioning info, there is the article TorizonCore Containers Tags and Versioning.

Have a good one.

Best Regards
Kevin

1 Like
28

Hi Kevin,

I am working together with @bgo.

The latest build Apalis iMX8, 6.2.0-devel-20230402+build.228 (2023-04-02) looks quite useful.
The latest Torizon Chromium Container with tag: 2.7.0-20220825 has the chromium version 101(New in Chrome 101 - Chrome Developers from 2022-04-26).
The version 111 (New in Chrome 111 - Chrome Developers from 2023-03-07) is released and recommended now.

Is there a configuration change that the next the quarterly release 6.2 will also make an update on docker hub to chromium version 111?
That would help us really. If not, can you give us an indication when there be an update to chromium version 111?

Thank you in advance.

Best regards

Mario

29

Hi @MWittig,

We do plan to eventually release a new version of the Chromium container based on Debian bookworm. However, not much has been done on this yet so I can’t say what version of Chromium this planned future container will release with.

Best Regards,
Jeremias