Opening Explorer with Win-E flashes Blender #116618

New Issue

kursad k · 2023-12-29T02:08:31+01:00

kursad k commented

2023-12-29 02:08:31 +01:00

System Information
Operating system: Windows 11
Graphics card: RTX 2070 / Intel IGPU on another PC.

Blender Version
Broken: 4.1.0 Alpha, branch: main, eb99895c972b
Worked: 3.1, 3.6, 4.0

Short description of error
Whenever I start a new file explorer using "win-e" Blender flashes in the background. What is interesting is that it even flashes when Blender is really in the background of other apps. I see it does this double flash.

I ran it with --debug-all and I see that it does a redraw (ghost_event_proc: ghost redraw 1) after I press Win-E to open an Explorer window

I tested it on another computer that just has an internal Intel GPU, and it has this issue too so I doubt that it is an Nvidia driver issue. Bear in mind that Blender is the only app that flashes, I think this is a Blender issue.

(Blender is running in the backround)


HWND 0000000000021132 mouse enter
HWND 0000000000021132 HCTX 0000000000000202 WT_CTXOVERLAP CXS_ONTOP
HWND 0000000000021132 mouse leave
HWND 0000000000021132 HCTX 0000000000000202 WT_CTXOVERLAP CXS_OBSCURED
ghost_event_proc: ghost redraw 1
UI_menutype_draw: opening menu "TOPBAR_MT_editor_menus"
UI_menutype_draw: opening menu "TIME_MT_editor_menus"
UI_menutype_draw: opening menu "VIEW3D_MT_editor_menus"

Here is a screen video showing the issue, as you can see Blender flashes and then the explorer window opens up.

Exact steps for others to reproduce the error
Open Blender.exe
Press Win+E to open an Explorer file browser window.

**System Information** Operating system: Windows 11 Graphics card: RTX 2070 / Intel IGPU on another PC. **Blender Version** Broken: 4.1.0 Alpha, branch: main, `eb99895c972b` Worked: 3.1, 3.6, 4.0 **Short description of error** Whenever I start a new file explorer using "win-e" Blender flashes in the background. What is interesting is that it even flashes when Blender is really in the background of other apps. I see it does this double flash. I ran it with `--debug-all` and I see that it does a redraw (`ghost_event_proc: ghost redraw 1`) after I press `Win-E ` to open an Explorer window I tested it on another computer that just has an internal Intel GPU, and it has this issue too so I doubt that it is an Nvidia driver issue. Bear in mind that Blender is the only app that flashes, I think this is a Blender issue. (Blender is running in the backround) ``` HWND 0000000000021132 mouse enter HWND 0000000000021132 HCTX 0000000000000202 WT_CTXOVERLAP CXS_ONTOP HWND 0000000000021132 mouse leave HWND 0000000000021132 HCTX 0000000000000202 WT_CTXOVERLAP CXS_OBSCURED ghost_event_proc: ghost redraw 1 UI_menutype_draw: opening menu "TOPBAR_MT_editor_menus" UI_menutype_draw: opening menu "TIME_MT_editor_menus" UI_menutype_draw: opening menu "VIEW3D_MT_editor_menus" ``` Here is a screen video showing the issue, as you can see Blender flashes and then the explorer window opens up. ![video](https://projects.blender.org/attachments/d4127aac-11f2-4f53-b269-e77818152130) **Exact steps for others to reproduce the error** Open Blender.exe Press Win+E to open an Explorer file browser window.

explorer_yqcla7R3aJ.mp4

1.5 MiB

kursad k added the

labels 2023-12-29 02:08:31 +01:00

Pratik Borhade commented

2023-12-29 05:50:02 +01:00

Hi, unable to replicate the issue but I observed similar problem when blender launched on intel iGPU: #97674

❤️ 1

kursad k commented

2023-12-29 05:57:13 +01:00

Thanks for testing. I can definitely confirm that "ghost_event_proc: ghost redraw 1" happens when explorer is launched with "Win-E" on multiple Windows machines whether Blender is the most front app or it is sitting idle in the background. See the video please, I can repeat this issue hundred times a day.

Somehow opening a new instance of Windows Explorer forces Blender to redraw.

Thanks for testing. I can definitely confirm that "ghost_event_proc: ghost redraw 1" happens when explorer is launched with "Win-E" on multiple Windows machines whether Blender is the most front app or it is sitting idle in the background. See the video please, I can repeat this issue hundred times a day. Somehow opening a new instance of Windows Explorer forces Blender to redraw.

Pratik Borhade commented

2023-12-29 06:04:52 +01:00

Yes, watched the video but still not able to redo the problem. Let's wait for others to verify this behavior (cc @Harley ).
BTW, do you have multiple monitors in setup? Maybe that will make some difference?

Yes, watched the video but still not able to redo the problem. Let's wait for others to verify this behavior (cc @Harley ). BTW, do you have multiple monitors in setup? Maybe that will make some difference?

kursad k commented

2023-12-29 06:39:49 +01:00

I have multiple monitors on one of the PCs, but not with the other one.

Pratik Borhade referenced this issue

2023-12-29 07:43:33 +01:00

Crash while baking the Line Art modifier #111457

kursad k commented

2023-12-29 07:48:43 +01:00

This sounds like a minor annoyance, but it could cause bigger performance and scene related issues down the road on Windows. It would be nice to get an opinion of a developer to see why it is happening. This might be an edge case too, but it is curious that can be repeated on completely unrelated Windows 11 PC hardware specs.

Jesse Yurkovich commented

2023-12-29 20:31:05 +01:00

I also cannot reproduce the issue. There are no ghost redraw messages in my trace. Win11, NVIDIA, 2 monitors (left-right). Are you using a WACOM tablet, or similar, as it looks like some of the notifications I see in your trace are coming in from Wintab/tablet software: WT_CTXOVERLAP CXS_OBSCURED. Have any drawing tablet devices ever been installed on the PCs you're experiencing this on?

I also cannot reproduce the issue. There are no ghost redraw messages in my trace. Win11, NVIDIA, 2 monitors (left-right). Are you using a WACOM tablet, or similar, as it looks like some of the notifications I see in your trace are coming in from Wintab/tablet software: `WT_CTXOVERLAP CXS_OBSCURED`. Have any drawing tablet devices ever been installed on the PCs you're experiencing this on?

❤️ 1

kursad k commented

2023-12-29 20:38:13 +01:00

@deadpin Thanks for testing it. This is really interesting. You can clearly see that the draw happens (first flashes then prints the draw) in the terminal while Blender is in the background when I recorded the video, you might need to slow it down in Blender video editor to see the affect.

I have Wacom display and a Wacom tablet with my desktop. The other one is a laptop with no dedicated GPU, except the internal Igpu. However that one also has a Wacom display as part of the laptop screen. Would a Wacom driver causing a draw?

What is even more fascinating is that I do not have this issue with Blender 3.1, 3.6 and 4.0 (ones I have locally), but 4.1 has it. So a new change in 4.1 is causing it. I tested it 4.1 factory defaults, and that one still displays the issue.

@deadpin Thanks for testing it. This is really interesting. You can clearly see that the draw happens (first flashes then prints the draw) in the terminal while Blender is in the background when I recorded the video, you might need to slow it down in Blender video editor to see the affect. I have Wacom display and a Wacom tablet with my desktop. The other one is a laptop with no dedicated GPU, except the internal Igpu. However that one also has a Wacom display as part of the laptop screen. Would a Wacom driver causing a draw? What is even more fascinating is that I do not have this issue with Blender 3.1, 3.6 and 4.0 (ones I have locally), but 4.1 has it. So a new change in 4.1 is causing it. I tested it 4.1 factory defaults, and that one still displays the issue.

Harley Acheson commented

2023-12-29 20:39:59 +01:00

First, I do see this. But not seeing this as our problem...

While Blender is in the background (not active), launching Explorer with Win-E will cause blender to redraw once.

We're basically getting an extra WM_PAINT message from the system and so redrawing. If we didn't redraw at that point we would instead become a grey screen.

Is it just Blender? Nope. I see the exact same behavior with "Notepad++" and here is a complaint about the same behavior with the "foobar2000" audio program: https://hydrogenaud.io/index.php/topic,124874.0.html

This looks to be just a change in behavior in the new explorer in Windows 11. Is it a performance issue? No, this is literally just an extra redraw of the interface.

First, I do see this. But not seeing this as our problem... While Blender is in the background (not active), launching Explorer with Win-E will cause blender to redraw once. We're basically getting an extra WM_PAINT message from the system and so redrawing. If we didn't redraw at that point we would instead become a grey screen. Is it just Blender? Nope. I see the exact same behavior with "Notepad++" and here is a complaint about the same behavior with the "foobar2000" audio program: https://hydrogenaud.io/index.php/topic,124874.0.html This looks to be just a change in behavior in the new explorer in Windows 11. Is it a performance issue? No, this is literally just an extra redraw of the interface.

❤️ 1

kursad k commented

2023-12-29 20:46:07 +01:00

@Harley This was not there until 4.1 Please see my previous comment. 3.6, 3.1 and 4.0 do not have this issue, I just tested them on the same system. I do not have it with Notepad++ btw, but I see it happens with Godot 4

Jesse Yurkovich commented

2023-12-29 20:56:10 +01:00

That's good info to have. Why didn't you say in your initial description that prior versions worked. I'll modify the description at least.

In the meantime, you can use archived builds to try to narrow down the problem. There's 4.1 builds as far back as 2023-10-01, can you try binary searching a few of them to see when the problem occurred? Start with that Oct 1st build to see if it was present even at that point: https://builder.blender.org/download/daily/archive/

That's good info to have. Why didn't you say in your initial description that prior versions worked. I'll modify the description at least. In the meantime, you can use archived builds to try to narrow down the problem. There's 4.1 builds as far back as 2023-10-01, can you try binary searching a few of them to see when the problem occurred? Start with that Oct 1st build to see if it was present even at that point: https://builder.blender.org/download/daily/archive/

❤️ 1

kursad k commented

2023-12-29 21:12:28 +01:00

@deadpin I assumed that the issue was there in the previous versions. I will test these archives.

Harley Acheson commented

2023-12-29 21:25:17 +01:00

@LazyDodo

I'm fairly certain you won't be able to recreate this issue since you are on Windows 10.

But this issue goes away if I do only this:

diff --git a/intern/ghost/intern/GHOST_SystemWin32.cc b/intern/ghost/intern/GHOST_SystemWin32.cc
index 90ec4577370..a73cc48e3e6 100644
--- a/intern/ghost/intern/GHOST_SystemWin32.cc
+++ b/intern/ghost/intern/GHOST_SystemWin32.cc
@@ -2188,8 +2188,10 @@ LRESULT WINAPI GHOST_SystemWin32::s_wndProc(HWND hwnd, uint msg, WPARAM wParam,
         case WM_ERASEBKGND:
           /* An application sends the WM_ERASEBKGND message when the window background must be
            * erased (for example, when a window is resized). The message is sent to prepare an
            * invalidated portion of a window for painting. */
+          eventHandled = true;
+          break;
         case WM_NCPAINT:
           /* An application sends the WM_NCPAINT message to a window
            * when its frame must be painted. */
         case WM_NCACTIVATE:

Not seeing anything not working as expected with the above change, we still draw exactly when I think we should. Does this ring a bell?

@LazyDodo I'm fairly certain you won't be able to recreate this issue since you are on Windows 10. But this issue goes away if I do only this: ```Diff diff --git a/intern/ghost/intern/GHOST_SystemWin32.cc b/intern/ghost/intern/GHOST_SystemWin32.cc index 90ec4577370..a73cc48e3e6 100644 --- a/intern/ghost/intern/GHOST_SystemWin32.cc +++ b/intern/ghost/intern/GHOST_SystemWin32.cc @@ -2188,8 +2188,10 @@ LRESULT WINAPI GHOST_SystemWin32::s_wndProc(HWND hwnd, uint msg, WPARAM wParam, case WM_ERASEBKGND: /* An application sends the WM_ERASEBKGND message when the window background must be * erased (for example, when a window is resized). The message is sent to prepare an * invalidated portion of a window for painting. */ + eventHandled = true; + break; case WM_NCPAINT: /* An application sends the WM_NCPAINT message to a window * when its frame must be painted. */ case WM_NCACTIVATE: ``` Not seeing anything not working as expected with the above change, we still draw exactly when I think we should. Does this ring a bell?

❤️ 1

Harley Acheson commented

2023-12-29 22:12:39 +01:00

@LazyDodo

I think I see this now.

If we have a null background brush in our class, prior to #115968, then we don't get this problem. But then we DO get a white flash when the application starts and before we start painting ourselves.

But if set a background brush, in our case now GetStockObject(DKGRAY_BRUSH) we get a nice dark grey background that matches our initial GL clear color. So the startup looks awesome. But we get an extra redraw when Explorer launches. That only goes away if we suppress WM_ERASEBKGND. More details here: https://stackoverflow.com/questions/12073721/what-is-the-correct-way-to-suppress-wm-erasebkgnd

So go back to using a null hbrBackground or suppress WM_ERASEBKGND?

@LazyDodo I think I see this now. If we have a null background brush in our class, prior to #115968, then we don't get this problem. But then we DO get a white flash when the application starts and before we start painting ourselves. But if set a background brush, in our case now `GetStockObject(DKGRAY_BRUSH)` we get a nice dark grey background that matches our initial GL clear color. So the startup looks awesome. But we get an extra redraw when Explorer launches. That only goes away if we suppress WM_ERASEBKGND. More details here: https://stackoverflow.com/questions/12073721/what-is-the-correct-way-to-suppress-wm-erasebkgnd So go back to using a null hbrBackground or suppress WM_ERASEBKGND?

❤️ 1

Harley Acheson added

and removed

labels 2023-12-29 22:12:58 +01:00

Harley Acheson self-assigned this 2023-12-29 22:13:07 +01:00

Harley Acheson commented

2023-12-29 22:55:38 +01:00

@LazyDodo : never mind, the initial background isn't painted with the class brush if we don't pass along WM_ERASEBKGND. So just going back to a null brush.

❤️ 1

Harley Acheson referenced a pull request that will close this issue

2023-12-29 23:10:38 +01:00

Fix #116618: Win32 Use Null for Background Window Brush #116642

Harley Acheson referenced this issue from a commit

2023-12-29 23:12:21 +01:00

Fix #116618: Win32 Use Null for Background Window Brush

Harley Acheson closed this issue

2023-12-29 23:12:22 +01:00

Blender Bot added

Status

Resolved