Closed mattkae closed 10 months ago
@mattkae were you able to confirm this DTRT as far as smooth boot is concerned?
I don't think this can be to address seamless boot directly: that needs the server to defer compositing until content from the client app is available. This just means that compositing will start without a background (as you say, just like mir_demo_server, or miriway without swaybg).
The idea might be to simplify detecting whether there's an app providing content by preventing the "wallpaper client" from providing content. But I'm not convinced that's necessary, or a good idea.
@Saviq @AlanGriffiths Alan is right on this one. The compositor itself is going to clear the screen once it is ready to start drawing surfaces. As Alan said, we could make it not do anything until it first has a "renderable" to render. Otherwise, we could do the tougher task of reading in the plymouth buffer and rendering that ourselves until the user has supplied another renderable.
I don't think this can be to address seamless boot directly: that needs the server to defer compositing until content from the client app is available. This just means that compositing will start without a background (as you say, just like mir_demo_server, or miriway without swaybg).
As Alan said, we could make it not do anything until it first has a "renderable" to render.
Yeah that's what I think we should be doing. Off the top I can't think of why it couldn't be the default behaviour?
The idea might be to simplify detecting whether there's an app providing content by preventing the "wallpaper client" from providing content. But I'm not convinced that's necessary, or a good idea.
Do you have another approach in mind? Why / how would we want to treat the background client in a special way? In truth, we could probably (when this, or similar, option is engaged) just delay the background client altogether by $timeout
, no smaller than the diagnostic timeout?
Otherwise, we could do the tougher task of reading in the plymouth buffer and rendering that ourselves until the user has supplied another renderable.
That wouldn't change much compared to the above, would it?
I mean, not until we start doing something more with the buffer.
OK so this, together with MirServer/mir#3086 looks exactly like what we need :)
I'm just trying to think about what's the best user experience. A --wallpaper-timeout
came to mind, but then isn't the diagnostic what we'd like to see first, if configured? So the wallpaper timeout would have to be counted towards the diagnostic one.
But do we really need another timeout? The behaviour here, I think, is mostly correct - the first thing we see (with --wallpaper=false
) is the diagnostic. We still see the wallpaper if there is no diagnostic text, so that's the icky bit - alternative would be to stay on the splash screen indefinitely, but maybe that's what we should do?
If someone disabled the wallpaper, and does not have the diagnostic set up - maybe the splash screen should stay on screen?
OK so this, together with MirServer/mir#3086 looks exactly like what we need :)
I'm just trying to think about what's the best user experience. A
--wallpaper-timeout
came to mind, but then isn't the diagnostic what we'd like to see first, if configured? So the wallpaper timeout would have to be counted towards the diagnostic one.But do we really need another timeout? The behaviour here, I think, is mostly correct - the first thing we see (with
--wallpaper=false
) is the diagnostic. We still see the wallpaper if there is no diagnostic text, so that's the icky bit - alternative would be to stay on the splash screen indefinitely, but maybe that's what we should do?If someone disabled the wallpaper, and does not have the diagnostic set up - maybe the splash screen should stay on screen?
Maybe if there isn't any diagnostic text but there is some error, then we show some default diagnostic text? I agree that it feels weird to show the background out of nowhere when there's an error. I'm up for either some default text or just keeping the splash on screen. Although, leaving the splash on screen makes it a bit trickier to debug from a user's perspective
Maybe if there isn't any diagnostic text but there is some error, then we show some default diagnostic text? I agree that it feels weird to show the background out of nowhere when there's an error.
It's not that there is an error, necessarily. And even if there is - Frame can't know what it is.
I'm up for either some default text or just keeping the splash on screen. Although, leaving the splash on screen makes it a bit trickier to debug from a user's perspective
Well, that's exactly what the diagnostic is for. The "user" in the case of Frame shouldn't be doing any debugging, just call the number that's on screen :)
And just to confirm we're DTRT:
The before:
And the after:
The white flash is rendered by Flutter, so it's in the application author's hands now.
@mattkae so personally I'm erring on --wallpaper=false
doing what it says on the tin… just not draw the wallpaper, ever. If there is a diagnostic on, that will pop up as usual.
@AlanGriffiths thoughts?
Well, that's exactly what the diagnostic is for. The "user" in the case of Frame shouldn't be doing any debugging, just call the number that's on screen :)
That makes sense to me! So if they fail to set up the diagnostic and the wallpaper is turned off, then we keep showing the splash. Does that sound right?
And just to confirm we're DTRT:
And yup, that's what I would expect. The splash is shown all the way up to the first render of the app.
That makes sense to me! So if they fail to set up the diagnostic and the wallpaper is turned off, then we keep showing the splash. Does that sound right?
Yeah exactly.
And just to confirm we're DTRT:
And yup, that's what I would expect. The splash is shown all the way up to the first render of the app.
Oh I wasn't asking ;D
@Saviq I have implemented + tested only showing the diagnostic screen when we have diagnostic info :+1:
@mattkae that if/else dance looks like it could use some rework?
@mattkae that if/else dance looks like it could use some rework?
As in its too verbose, or is it incorrect?
As in its too verbose, or is it incorrect?
I mean this:
and then this:
The control flow got quite twisted?
Depends on
To test
sudo make install
The splash should still be on the screen
What's new?
wallpaper_enabled
flag that is set to true by defaultBackgroundClient::Self::draw_screen
if we have errors or the wallpaper is enabled