Details

Reviewers

Brecht Van Lommel (brecht)
Ray Molenkamp (LazyDodo)

Maniphest Tasks

T62651: Dual monitor on separate graphics card driver error

Commits

rBfd1078e1055e: Fix T62651: Win32 Multiple Adapters Warning

Summary

Show a more instructive error message for users who have plugged
multiple monitors into multiple display adapters. And do not exit
if unable to open a child window when in this state.

OpenGL on Windows is a bit odd when you have multiple adapters. Only the primary adapter can use hardware-accelerated OpenGL, while the others will only be able to use the MS OpenGL 1.1 software renderer. When users plug their multiple monitors into separate adapters Blender will exit with an error message if any of our windows gets such a context.

The error message is not instructive in this case: "a graphics card and driver with support for OpenGL 3.3 or higher is required. Installing the latest driver for your graphics card may resolve the issue."

It is also a problem that Blender always exits if any window gets this context. So if the main window opens fine but a secondary window does not, then blender dies regardless.

This patch moves the error message out of newDrawingContext and directly into the window constructor. It then has a different message for users that have more than one monitor. "Unable to obtain a hardware-accelerated OpenGL drawing context for this monitor. Plugging all your monitors into your primary adapter might resolve the issue."

And then it only calls exit if this is for a parent window, as we are not going to get a failing child window unless we have a successful parent window.

We are now getting more reports of this issue than before because we are dealing with multiple monitors better. It used to be that Blender always opened on the primary monitor and any child windows opened on the same monitor as the parent. We now handle that properly in that we will restore all windows to the monitors, positions, and sizes as they were saved. But this does mean the old behavior could hide this issue while the fixed behavior can expose it.

Diff Detail

Repository: rB Blender

Event Timeline

Harley Acheson (harley) requested review of this revision.Jan 20 2022, 7:08 PM

Harley Acheson (harley) created this revision.

I also had to sneak in an initialization of m_Bar to null. Currently if the constructor does not complete then m_Bar will contain random values that will crap out in the destructor.

nice try, but no dice, if we have to revert this diff for some reason, there's no need for that fix to be reverted as well, just land it as a separate cleanup commit, no need to go though additional review.

@Ray Molenkamp (LazyDodo) - nice try, but no dice...

I removed that m_Bar initialization, will commit separately.

Harley Acheson (harley) added a task: T62651: Dual monitor on separate graphics card driver error.Jan 21 2022, 9:07 PM

I wonder if it's possible to work around this issue by creating the window on one monitor and then moving it to another?

Since I don't remember reports about moving a window causing issues, and I can't imagine Windows is able to switch OpenGL driver while doing that.

intern/ghost/intern/GHOST_WindowWin32.cpp
134–135	Rather than replacing the text about OpenGL 3.3 and installing the latest driver, I'd rather we add extra information for multiple monitors if they are there. Since the existence of multiple monitors does not necessarily mean that's the cause. Something like: A graphics card and driver with support for OpenGL 3.3 or higher is required Plugging all monitors into the primary graphics card might resolve the issue. Installing the latest driver for your graphics card might also help. Blender - Unsupported Graphics Card Configuration

This revision now requires changes to proceed.Jan 21 2022, 10:01 PM

@Brecht Van Lommel (brecht) - I wonder if it's possible to work around this issue by creating the window on one monitor and then moving it to another?

That would probably work. But if it did it would just eliminate most of these reports not all. I'm thinking we always create windows on the primary monitor, then move them to their final destination before showing. We could still have some users with their primary monitor plugged into their secondary adapter, although this is far less likely

So lets do this patch then I'll experiment with the other idea. I don't have a secondary adapter though - all my monitors are in the only adapter in my computer - but should be able to get something that probably works and does no harm.

Harley Acheson (harley) planned changes to this revision.Jan 21 2022, 10:23 PM

Pratik Borhade (PratikPB2123) awarded a token.Jan 24 2022, 5:36 AM

Harley Acheson (harley) edited the summary of this revision. (Show Details)Jan 24 2022, 6:23 AM

@Brecht Van Lommel (brecht) - ...I'd rather we add extra information for multiple monitors...

Yes, done. Here are the two versions, left when only one monitor is detected, the right when more than one:

Brecht Van Lommel (brecht) accepted this revision.Jan 24 2022, 9:15 PM

This revision is now accepted and ready to land.Jan 24 2022, 9:15 PM

Landing Target is 3.2, after D13886: Win32: Initialize GHOST_WindowWin32 Members

@Ray Molenkamp (LazyDodo) - Does this look reasonable to you?

Harley Acheson (harley) mentioned this in D13886: Win32: Initialize GHOST_WindowWin32 Members.Jan 28 2022, 8:00 PM

no need for further review, just fix it before landing.

intern/ghost/intern/GHOST_WindowWin32.cpp
137	not super fond of the use of the ternary operator here, I really had to hunt for that `:` initially I was convinced it was missing. a regular if / else will likely break up this wall of text nicely