Page MenuHome

Incorrect Title Bar size when moving Window between monitors with different DPI and Scaling - Windows 10
Closed, ArchivedPublic


System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: Intel(R) Iris(R) Graphics 540 Intel 4.5.0 - Build

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 13:50, hash: rB06312c6d2db8
Worked: (optional)

Short description of error
Title Bar size remains constant size (in pixels) when moving Blender Window between monitors with different DPI and Scaling settings in WIndows 10

Exact steps for others to reproduce the error

  1. Open Blender in High DPI monitor. Everything appears properly Scaled.
  2. Move the same window to a Normal DPI monitor. Everything in the Blender Window appears properly scaled, except for the Window Titlebar, which appears to be too big. This is because the Titlebar retains the height in pixels from the monitor it was originally opened on.

Reversing this procedure and opening Blender on a Normal DPI monitor and moving to a High DPI monitor also causes very small Titlebar.

Solution would be to reset the height of the Titlebar whenever the window is moved to a new monitor, just as the rest of the Blender Interface is redrawn for every such move.

Event Timeline

To be honest, this looks like a good feature to me as I am seeing it the opposite way...

In the top of the following capture, we are seeing Blender in the back and notepad in front on a monitor with increased scaling. Notice the Notepad titlebar is larger. The bottom image shows both applications on a monitor set to 100%. Here they have titlebars of the same size.

Therefore the "error" is that the titlebar of Blender is staying at it's minimum size and not getting larger as the monitor scale increases. It is never that it is larger than it has to be, but remains as small as possible. This only seems like a good thing.

Therefore the "error" is that the titlebar of Blender is staying at it's minimum size and not getting larger as the monitor scale increases. It is never that it is larger than it has to be, but remains as small as possible. This only seems like a good thing.

The following is a screenshot of Blender where I opened it on a 1080p monitor and subsequently moved it to a High-DPI monitor:

It is apparent that the Title Bar is quite small compared to the rest of the UI (which appears the right size) and in my experience becomes much harder to press the buttons on it. Thus, I would have to disagree that it is staying at it's minimum size.

I'm not sure if you tested this by simply adjusting the scaling on just one monitor (where the current behavior may be acceptable) or actually tested it on a High-DPI monitor, where >100% Scaling becomes a necessity for usability. I'm using a Surface Pro 4 with a display Size of 12.3", which results in the Titlebar taking up less than 1/4" of physical height and makes it harder to use.

the Title Bar is quite small compared to the rest of the UI (which appears the right size)

Ah... I did realize that the size of the titlebar was not following the convention of the other windows on the monitor with higher scaling. However, because your original comment included "which appears to be too big" I had assumed that you were complaining about it being too big, not too small.

But you are right, if the titlebar remains too small it would be harder to click the "close" and "minimize" buttons.

We don't technically draw the titlebar itself. The operating system draws that part and the outer frame while Blender's client area is inside that. Looking at other apps while dragging between the monitors it looks like the non-client area is redrawn with the new new scaling as soon as it is just halfway onto the monitor. So the titlebar grows or shrinks at the half-way mark. So I'm guessing there might be a windows message that we have to respond to and then possibly reply that it is okay to redraw? Someone with more Windows API experience might know what's going on.

Thanks for this report; it was well-written and quite interesting.

This message, WM_DPICHANGED, seems to be sent to the window when dragged to a monitor with differing effective dpi. It even gives us suggested new size and position so we handle the transition correctly:

There is also a WM_DPICHANGED_BEFOREPARENT sent to children of the main window so they can redraw first I think

But not sure what we would do to force, or allow, a redrawing of the non-client area so that the titlebar is redrawn.

Hmmmm.... looking further we might have to use this instead:

like this:

    return (DefWindowProc(hwnd, message, wParam, lParam));

So ideally both. We'd call EnableNonClientDpiScaling(hwnd); during window creation so that Windows will scale the non-client areas. But also deal with the WM_DPICHANGED message to resize our windows as they are moved about or people change their scale or resolution.

I should have highlighted the case of moving from Low DPI to High DPI in my initial report, since that would have more clearly demonstrated the hampered usability. The case when moving from High-DPI to Low-DPI still results in a bigger than necessary Titlebar which eats up valuable vertical space.

Thank you for testing different applications and confirming my suspicion that Blender indeed does not behave like native apps. I have almost no experience with the win32 API and the Blender codebase, to contribute to fixing this issue. I'd be happy to assist in any other way if required, e.g, test new builds.

I did a little digging around the code base and found that Non-Client DPI Scaling had been implemented but turned off due to the bug report T51959. (Commit rB0584c5ba8e73).

The bug seem to be linked to a version of Intel Graphics Driver for Iris 540. Looking at the Driver Update History for Surface Pro 4, the version of the Graphics Driver must have been Currently, the latest driver for the model is

Therefore it seems worthy to revert rB0584c5ba8e73 and check if the original bug has been resolved with the newer driver. This would fix the current bug as well.

I've not tried setting up the complete build system to try and build Blender from source. If any Windows Developer would be willing to apply this fix and build an executable, I would be happy to test it.

Germano Cavalcante (mano-wii) lowered the priority of this task from 90 to 30.Dec 6 2019, 3:09 PM

Recently a related fix has been committed.
@Bharat Kambalur (bkambalur), could you test with the latest blender build?

Philipp Oeser (lichtwerk) changed the task status from Unknown Status to Unknown Status.Dec 17 2019, 12:47 PM
Philipp Oeser (lichtwerk) claimed this task.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.