Incorrect Title Bar size when moving Window between monitors with different DPI and Scaling - Windows 10 #67017

New Issue

Bharat Kambalur · 2019-07-15T22:16:11+02:00

Bharat Kambalur commented

2019-07-15 22:16:11 +02:00

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

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 13:50, hash: 06312c6d2d
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

Open Blender in High DPI monitor. Everything appears properly Scaled.
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.

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: Intel(R) Iris(R) Graphics 540 Intel 4.5.0 - Build 24.20.100.6299 **Blender Version** Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-07-11 13:50, hash: `06312c6d2d` 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. ![Blender 2.8 RC Incorrect Titlebar Size.png](https://archive.blender.org/developer/F7611573/Blender_2.8_RC_Incorrect_Titlebar_Size.png) 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.

Bharat Kambalur commented

2019-07-15 22:16:11 +02:00

Added subscriber: @bkambalur

Harley Acheson commented

2019-07-16 02:27:50 +02:00

Added subscriber: @Harley

Harley Acheson commented

2019-07-16 02:27:50 +02:00

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.

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. ![scaling.png](https://archive.blender.org/developer/F7611951/scaling.png) 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.

Bharat Kambalur commented

2019-07-16 02:46:13 +02:00

In #67017#723396, @Harley wrote:
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.

> In #67017#723396, @Harley wrote: > 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: ![image.png](https://archive.blender.org/developer/F7611960/image.png) 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.

Harley Acheson commented

2019-07-16 05:23:50 +02:00

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.

> 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.

Harley Acheson commented

2019-07-16 05:37:38 +02:00

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:

https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged

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:

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enablenonclientdpiscaling

like this:

case WM_NCCREATE:
{
    EnableNonClientDpiScaling(hwnd);
    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.

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: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged 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: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enablenonclientdpiscaling like this: ``` case WM_NCCREATE: { EnableNonClientDpiScaling(hwnd); 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.

Bharat Kambalur commented

2019-07-16 05:46:10 +02:00

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 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.

Bharat Kambalur commented

2019-07-16 14:27:31 +02:00

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 #51959. (Commit 0584c5ba8e).

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 21.20.16.4627. Currently, the latest driver for the model is 24.20.100.6299.

Therefore it seems worthy to revert 0584c5ba8e 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.

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 #51959. (Commit 0584c5ba8e). The bug seem to be linked to a version of Intel Graphics Driver for Iris 540. Looking at the [Driver Update History ](https://support.microsoft.com/en-us/help/4023489/surface-surface-pro-4-update-history) for Surface Pro 4, the version of the Graphics Driver must have been 21.20.16.4627. Currently, the latest driver for the model is 24.20.100.6299. Therefore it seems worthy to revert 0584c5ba8e 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 commented

2019-12-06 15:09:38 +01:00

Added subscriber: @mano-wii