I understand the problem, but I am not familiar with the fix progress. Is it fixable? I’d be more into fixing the bug than dealing with workaround, but if this is not possible, okay
I guess that it is not a happy coincidence that Windows, Red Hat and perhaps MacOS (?) choose black for the OS initialization. Maybe it is technically near impossible to have flicker-free without cheating a bit.
Maybe we can have an experiment with a black background and we might end up prefering it aesthetically?
1 Like
@vanvugt yes that worked. Thanks. I do not see purple screen. I tried rebooting and booting up from cold boot.
Maybe instead of changing the GDM background to black, just have it do a quick (0.25s?) crossfade from black to purple? I don’t know how hard that would be to do but it sounds like a better option to me.
Yes I have now confirmed on an HP laptop also that that’s the fix. If you get an unwanted purple screen between the two black screens then you need to do this:
sudo update-grub
@seb128, this feels like a missing step from the installation of plymouth-theme-spinner which should be automated.
1 Like
@mohan-ram, I agree a progress bar would be nice. But the bigger problem I find with Plymouth is that it starts so late it almost shouldn’t exist at all:
|-----------------|----------------|---|--+ Login screen
BIOS Kernel boot ^ Plymouth animation
|<---- animation not possible ---->|
In my experience on many machines, the Plymouth animation seems to start too late to be useful and ends almost immediately.
Flickerfree boot is still useful, because that will get us a consistent screen from end-to-end. But if you want something animated by Plymouth then that can only occur in the final section in the above diagram.
In theory we could start animating during kernel boot, but that would probably be a kernel project and not involve Plymouth.
5 Likes
It is not really a matter of aesthetic in this case, we already had black and moved to purple, we know how it was. If we change to black it will only be to avoid this annoying flickering, but according to @vanvugt reply, it seems the fix is ready, so I will wait a little before changing GDM again.
I’m going to have a look. Do you understand what is changing in the grub config there by triggering an update?
Right, also we should keep in mind at this point that it hasn’t been decided yet to switch the default to the new theme.
The boot is only going to be really flickerfree for a small part of the users so we need to decide on what we think looks the best when the experience isn’t right, the new theme or the old one?
2 Likes
I’m going to have a look. Do you understand what is changing in the grub config there by triggering an update?
No idea, sorry.
This is a good point, I’d say I will favor the experience over the style
@vanvugt ah, guess mine takes a bit longer because my test machine is on the slower end. Will this work on a AMD hardware, I do have faster HP laptop with AMD hardware with an SSD.
@seb128 just installed Ubuntu daily build on my HP laptop which runs AMD video card, and tried out flickerfree boot and it worked. If you need more info let me know.
I’m curious about how people feel, so here’s a non-binding poll…
- I have tried flickerfree boot and would like it to be default in 19.10.
- I have tried flickerfree boot and would not like it to be default in 19.10.
- I have not tried flickerfree boot and would like it to be default in 19.10.
- I have not tried flickerfree boot and would not like it to be default in 19.10.
0 voters
2 Likes
If it’s just a black screen with a small Ubuntu logo at the bottom, we could only talk about taking our yaru spinner instead of that generic one
Now tracking all flickerfree boot bugs using this tag:
I can’t propose changes any more than anyone else. 
Though if it was up to me then I would get rid of the spinner completely. I think it’s pointless as mentioned above in Testing flickerfree boot - #19 by vanvugt.
2 Likes
Alright, just in case you go with a spinner it would be good to take the one the desktop also uses
“By the way”, yet very offtopic: do you know where gnome-shell sucks up the spinner? I edited the SVG we have in our gnome shell theme (which uses the files from upstream), yet it is still the spinner from upstream. Talking about gnome shell, not gtk/icon/cursor, which is perfectly theme-able
Is this suppose to only work on GNOME? I installed Kubuntu daily build of 19.10 and it does seem to work on that.