Avoid blank white screen while chromium starts up

As @drew.tx suggested to post this issue here:
We are using your Docker image torizon/chromium:3 to display our locally hosted webapp. After Torizon booted up, there is shortly a white blank screen coming from Chromium until our webapp (in a dark layout) loads (see video: Üsofilm Cloud).
This is a Chromium issue as it doesn’t happen with the cog browser that we also reviewed recently, but as with it our slider input component wasn’t draggable and the performance on some animations was worse than in Chromium it was no option in the end.
So, I tried to find some flag that could change the behavior of Chromium to startup with a black background instead of white, but until now I wasn’t successful (we use a custom build based on your container, just changing the Chromium startup command to add some arguments, e.g. disable pinch to zoom).
This is what I tried:

Starting Chromium with the command line flags:
--force-dark-mode --default-background-color=000000

I also hardcoded the background color to be black in my index.html so it applied before any JS or other external file was loaded:

    <style type="text/css">
        html, body {
            width: 100vw;
            background-color: black;
            min-height: 100vh;
            height: 100vh;
            left: 0;
            top: 0;
        }
    </style>

Maybe your team has any other suggestion that might fix this blank white screen at Chromium startup?
It would be very nice if we could fix this.

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Addressing the issue of the blank white screen on Chromium startup within the Torizon environment requires a nuanced approach, as Chromium’s default behavior and loading sequence play significant roles here. Your attempts to mitigate this by using --force-dark-mode and --default-background-color=000000 flags, as well as hardcoding the background color in your HTML, are steps in the right direction. However, these measures might not influence the initial loading screen directly due to how Chromium handles its startup sequence and splash screen.

One potential workaround to consider involves the use of a lightweight window manager in conjunction with the Chromium browser within your Docker container. This approach can allow for more control over the window’s appearance before and during the Chromium startup process. For instance, you could configure the window manager to set a black background or display a custom splash screen that matches your web app’s theme until Chromium fully loads and displays your web application.

Another approach could involve modifying the Chromium source code to change the default background color during the startup phase. This method, however, is considerably more complex and requires a deep understanding of Chromium’s codebase, as well as maintaining your custom changes across Chromium updates.

Lastly, exploring Chromium’s command-line flags further might reveal additional parameters that could influence the startup behavior or allow for a custom splash screen. While the flags you’ve tried are a good start, Chromium has a vast array of flags, and there might be others that could more effectively achieve the desired result.

Implementing a lightweight window manager or splash screen solution within your Docker container involves configuring the window manager to start before Chromium and setting it up to either display a black background or a custom splash screen. This setup can be achieved through modifications to your Dockerfile and startup scripts, ensuring the window manager is properly configured and launched before initiating Chromium.

If you decide to explore modifying the Chromium source code, it’s essential to be prepared for a significant investment in time and resources, both for the initial modifications and for ongoing maintenance.

In summary, while there isn’t a straightforward flag or setting in Chromium to change the initial blank screen color, combining a lightweight window manager with your Docker setup or exploring deeper customizations to Chromium itself are viable paths to explore to mitigate this issue.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Basic Linux Commands | Toradex Developer Center.

@lbruhn-cw in addition to what the AI assistant suggested, there are some other possibilities listed in this post. I’ve not had a chance to try any of them but maybe there is something helpful in there.

I’ve also asked internally as we have engineers who know much more about Chromium than me.

Drew

Hi @drew.tx
Thanks for your reply.
I had a look into post you shared, but it turns out that the bug described there is supposed to be fixed in Chromium Version 59 in 2017 and the solution to change the custom style sheet isn’t supposed to work anymore either, because Chrome dropped user style sheet support in 2015 (according to the comments) - and I wasn’t able to find one in your chromium container so they are probably right.
I hope your colleges have any ideas.
How would it work to get around the issue by using a custom window manager? Is that referring to Weston? Maybe you can help me with some steps to try that out?

Regards,
Lasse

Hi @lbruhn-cw

I suspect the custom window manager route would get pretty complicated. Let’s hold that option until we exhaust other choices.

Drew

Hello @lbruhn-cw,

You should be able to do this by using the --force-dark-mode argument in Chromium.

Please note that this must be added under chromium_parms_extended in the /usr/bin/start-browser script: torizon-containers/debian-docker-images/imx/chromium/start-chromium.sh at stable · torizon/torizon-containers · GitHub

Best Regards,
Bruno

Hi @bruno.tx ,

thanks for you answer.
I’ve added it directly to the exec line in /usr/bin/start-browser like so:

exec chromium $chromium_parms_base $chromium_parms_extended --disable-pinch --overscroll-history-navigation=0 --disable-features=OverscrollHistoryNavigation --force-dark-mode --default-background-color=000000 $chromium_parms$URL

I think this should be exectly the same as adding it to chromium_parms_extended, right?

Even with this I still have the issue.

Regards,
Lasse Basedow

Hello @lbruhn-cw,

Yes, I would expect so.
However, can you test with only the --force-dark-mode argument in the chromium_parms_extended variable?
I have tested this and the starting screen was in dark-mode, as expected.
Maybe some of the other arguments are causing problems.

Best Regards,
Bruno

Hi @bruno.tx ,
thanks for your reply. I gave it another try like this, removing all the other custom flags:

chromium_parms_extended="$chromium_parms_extended --force-dark-mode"
exec chromium $chromium_parms_base $chromium_parms_extended $chromium_parms$URL

But the issue still exists.

Regards,
Lasse Basedow

Hello @lbruhn-cw,

Just to confirm, which version of Torizon Os are you using?

What url are you opening with Chromium?
If it is the one for your custom app, have you tested with other urls?

Just to clarify the test that I did, I added the --force-dark-mode argument as the first argument of chromium_parms_extended, directly on this line.

Best Regards,
Bruno

Hello @bruno.tx ,

we are using a custom build based on TorizonCore 6.6.1.
We open up a local URL of our custom app.

I will be on vacation for three weeks now, but I will check for a different URL when I’m back.

Regards,
Lasse

Hi @bruno.tx ,

I’m back from vacation and had the time to test a little further.
This time I added the flag exactly the way you described and without any other additional flags.
First I tried our custom app and the result is: dark grey screen (either from Weston or Chromium dark mode?) → blank white → our app.
Then I tried toradex.com and the result was the same: dark grey screen → blank white → toradex.com
The only difference is, that with toradex.com the blank white page displays only very short so you may not even notice and as the page also has a white background somewhere it’s probably not really a problem here.

I’m not sure if you have any other ideas how to fix this in Chromium. But an alternative could be to switch to cog browser that we’ve also tried and that doesn’t have this issue. Actually the overall performance seems to be even a bit better with cog so we would love to switch, but we’ve two problems with that:

  1. We have a component in our app with a collapsible box the can be folded/unfolded with an animation:

    The performance while unfolding the component for the first time is really bad. The animation is more like a jump (not smooth at all) and it takes so long that you think you clicked in the wrong place or the app is frozen.
  2. We have a slider input to control the screen brightness:

    The problem is that with cog it is not possible to drag the slider. Only clicking somewhere i and having the brightness jump is possible but no smooth adjustment on the fly. With Chromium this works.
    For these reasons we decided to stick with Chromium for now. Maybe you have some idea how we could tweak the cog browser to improve on these issues? Apart from that I asked our UX designer to come up with different ideas for these UI elements so that we might be able to change our application to work together with cog.

Seeing forward to your suggestions.

Regards,
Lasse

Hi @lbruhn-cw

I tested the solution from Bruno (running chromium with the --force-dark-mode)
And It seems to be working here.

What I see:

  1. light grey background (from Weston) →
  2. Dark gray background (from Chromium) →
  3. Dark background (from website page)

Would that be acceptable for your project?

I have attached my start-chromium.sh file.
start-chromium.sh (1.9 KB)

Hi @allan.tx ,

thanks for testing. With that GitHub repo page and your start-chromium.sh it is exactly the same at my side. This would also be acceptable for our app, but if I change the URL back to my local server hosting my app, the white screen is back.

However I have parental leave for one month now, so I will be back from Oct 14. Currently we are more looking into how we can adapt our UI to work better with cog, so we will probably “fix” this issue for us by switching to cog. Maybe you have any suggestions for our issues with the cog browser?

Thanks for your support

Regards,
Lasse

Hi @lbruhn-cw

Well, if it is working as intended for the github website but not for your local server website, I think you can solve it by taking a look how they implement the dark-mode and make some simple changes to adapt your webpage.

As for the cog browser,
I can’t really test the issues you mentioned as it is specific of your application,
I tested on some websites and I could not find any problem with the dropdowns, are you running the container for vivante? passing the -v /dev/galcore:/dev/galcore flag?

Just to sum this up:
In the end we switched now to the cog browser, as it fixes this issue for us and has also better overall performance. We just needed to remove some animations where the performance was really bad and to exchange the slider input component that could not be dragged. After these changes in the UI it’s working fine for us.

Thanks for your support!