-
Notifications
You must be signed in to change notification settings - Fork 570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Window white flash on init #914
Comments
I'm not personally seeing it, and at one time I spent considerable effort to avoid it. Are you on Windows 10? Is this a regression, ie do you still see it on older revs such as 9d7f3ab? |
Sorry, should have said I'm seeing it on Win7x64. |
I can confirm that I also have the white flash, both during startup and during resize at the edges, with my Windows 7. It's not there on my Windows 10 machine. |
I've been seeing this behavior for quite some time, so it's not a recent regression at least. It seems to be performance related, because I see the initial white flash when cold starting an app, but not on restarts. I can force it by sleeping in |
I managed to fix the white flash during resize in #915. It doesn't have an impact on the sleep based reproduction, however maybe the initial flash is caused by an issue that can't be represented by sleep. It will take time until I'll be able to know from my own experience, because I can't really reproduce cold starts easily. @Adarma how often do you see the white flash? Always? Does it still happen with the change in #915? |
Okay I managed to get a cold start again and #915 does not fix the white flash. I'm still leaning towards thinking that this is performance related. Giving this some further thought, perhaps going to a full event cycle at the beginning is a mistake. All the caches are going to be cold and we need to go through full layout etc. Perhaps a solution is to have some sort of |
I looked more closely into this and did some measuring with debug builds. The druid full event cycle is slow but remains under 8ms with the calculator example, which is what I'm using to test this. Most of the time during the first frame is actually spent creating the HWND render target, which clocks in at 39ms. I moved the HWND render target creation to |
I still get the same white flash with #916 Since you are testing with the I went back to e7ec2d1 Druid 0.5 and The other examples seem to run fine (but with the white flash). As you can see, I have a custom theme on Windows7, but that has never been an issue before. Not sure if it is all related. |
Okay so the completely unresponsive window is unexpected. I have not seen that myself nor have I heard of anyone else experiencing that. I doubt VS 2019 has any effect, I have a ton of Visual Studios installed in parallel and they cause no issues. The custom theme should not be an issue if other non-druid apps work fine. Is there any information printed in the console when calc launches? On my Windows 7 I get:
Do you have the same or something different? Beyond that, you could add some logging into log::debug!("Reached this point); Would be interesting to know if there's a hang of some sort, or if the event cycle is happening properly and the pixels just don't show up. |
I get the exact same printout to the console as you when launching calc, then an error when I force terminate it.
I just pulled today's master and ran all the examples again. It is only calc that hangs. I noticed while testing open_save, that launching the win7 open and save windows from it has the white flash too. So I tried other applications calling those and it happens with all of them too. So the white flash thing seems like it is due to this machine. If nobody else is experiencing it, the issue should probably be closed. Regarding the hang, I adding logging into core.rs as the first line in each:
That results in this:
|
Well you're just the only one who has reported it here. There can easily be lots of other people out there with the same issue. I would like to fix it. The debug log you provided is promising. It shows that let now = std::time::SystemTime::now()
.duration_since(std::time::UNIX_EPOCH)
.unwrap()
.as_secs();
log::debug!("{} > {:?}", now, event); This will help us understand what kind of events is it stuck dealing with. |
I have since discovered that if I rename So I guess I suspect a |
Rust incremental builds sometimes go bad indeed, I've seen some crazy phantom behavior that is resolved by |
Whatever caused the hang is gone now. Sorry about that tangent. |
Okay, I created a branch with debug messages - Run |
I ran
|
Okay, that's useful. Thanks for doing the test runs! It seems that the druid code parts aren't that slow. They work fast enough to deliver 60fps and are not the cause of the white flash. As for what is slow, there seem to be two things.
|
Its a company laptop, which I've been using for a few years. I doubt the drivers have been updated since it was first imaged, although updates are pushed out to it by the IT department. It is running 3 monitors from a docking station, so I'll check tomorrow the performance with just the laptop screen on. |
The specs aren't great but they should be good enough. I do also wonder if the multi-monitor situation has an effect, so that's worth checking out. It's also worth testing if the flash also appears when you compile with |
This was run with no monitors attached:
This is in --Release mode, also without monitors:
|
Looks like removing the monitors has a significant impact, and the release build also has some impact. Are you still seeing the white flash with In general this looks like it has mostly to do with your specific setup. Like I mentioned earlier, the druid code here doesn't account for much. In these latest tests the druid code accouts for just 10% of the time it takes between the window showing and Something is making Windows/Direct2D slow and I'm not sure what it is. |
Yes the white flash is still there without monitors and in release. |
Okay, I'll close this issue as there isn't anything we can change in druid to solve it right now. |
Is it possible to prevent the white flash that happens before the GUI is initially drawn?
Maybe just being able to choose black rather then a white flash is enough.
Seeing it in the examples on Windows.
The text was updated successfully, but these errors were encountered: