The Window size (client area) is incorrect when using Windows display driver.

[sliang951753]

LVGL version

v9.0.0

What happened?

When using lv_windows_create_display() to create LVGL display, the Window's client area always smaller than the specified screen resolution.
for example, lv_windows_create_display(L"LVGL Window", 1024, 600, 100, true, false);
then, the created window is at the resolution of 1024*600, however, its client area is smaller and about to 1000 * 550.

This is because the specified display resolution does not consider the window caption and client edge size.

Here's a possible fix for this issue.
In lv_windows_display_thread_entrypoint() function, calling AdjustWindowRectEx before CreateWindowExW.

` RECT rc = {0, 0, data->hor_res, data->ver_res};
AdjustWindowRectEx(&rc, window_style, FALSE, WS_EX_CLIENTEDGE);

HWND window_handle = CreateWindowExW(
                         WS_EX_CLIENTEDGE,
                         L"LVGL.Window",
                         data->title,
                         window_style,
                         CW_USEDEFAULT,
                         0,
                         rc.right - rc.left,
                         rc.bottom - rc.top,
                         NULL,
                         NULL,
                         NULL,
                         data);`

How to reproduce?

No response

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

[kisvegabor]

Thank you for reporting it!

@MouriNaruto could you take look at this issue?

[vwheeler63]

> HWND window_handle = CreateWindowExW(
>                          WS_EX_CLIENTEDGE,
>                          L"LVGL.Window",
>                          data->title,
>                          window_style,
>                          CW_USEDEFAULT,
>                          0,
>                          rc.right - rc.left,
>                          rc.bottom - rc.top,
>                          NULL,
>                          NULL,
>                          NULL,
>                          data);

I believe there are also 2 one-off errors in this call. Specifically:

width should be = rc.right - rc.left + 1 + (2 * edge_width);
height should be = rc.bottom - rc.top + 1 + (2 * edge_width) + title_bar_height;

or

width should be = rc.right - rc.left + 1 + (edge_width << 1);
height should be = rc.bottom - rc.top + 1 + (edge_width << 1) + title_bar_height;

if your compiler doesn't optimize multiplying by 2.

I am a little rusty on CreateWindowExW(), but what I remember about Win32 is that (using Win32 data):

Width = Right - Left
Height = Bottom - Top

and I am 100% certain that:

Right = 1 pixel PAST right edge, and
Bottom = 1 pixel PAST bottom edge.

Note: There are ways to create a window where the width and height passed are for the CLIENT AREA, which is what is wanted. This question/answer on stackexchange.com covers one way to do that.

Kind regards,
Vic

[MouriNaruto]

I will try to fix that.

Kenji Mouri

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

[kisvegabor]

@MouriNaruto did you have time to look into this?

[MouriNaruto]

I will look into this issue in the recent days.

Kenji Mouri

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "Abandoned" because there was no activity here for 14 days.

Remove the "Stale" label or comment else this will be closed in 7 days.

[MouriNaruto]

not stale

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "Abandoned" because there was no activity here for 14 days.

Remove the "Stale" label or comment else this will be closed in 7 days.

[kissa96]

How are we doing with this issue?

[MouriNaruto]

Actually, it should not have the issue when people use the simulator mode in the current stage

Note: My screen is 125% DPI scaling, so I set the zoom_level to 80% for rendering the content without scaling (1.25 * 0.8 = 1). It shows the client area is the same as which I set for the lv_windows_create_display.

Kenji Mouri

[kisvegabor]

Transferred to lv_port_pc_visual_studio.

[sliang951753]

Actually, it should not have the issue when people use the simulator mode in the current stage

Note: My screen is 125% DPI scaling, so I set the zoom_level to 80% for rendering the content without scaling (1.25 * 0.8 = 1). It shows the client area is the same as which I set for the lv_windows_create_display.

Kenji Mouri

Hello,

Please try the following parameters when initializing the windows display.
scale = 100%
allow_dpi = true
simulator_mode = false

I think you may reproduce this issue.

[MouriNaruto]

Actually, it should not have the issue when people use the simulator mode in the current stage
Note: My screen is 125% DPI scaling, so I set the zoom_level to 80% for rendering the content without scaling (1.25 * 0.8 = 1). It shows the client area is the same as which I set for the lv_windows_create_display.
Kenji Mouri

Hello,

Please try the following parameters when initializing the windows display. scale = 100% allow_dpi = true simulator_mode = false

I think you may reproduce this issue.

You need to use the simulator mode to achieve your needs by design. Read https://docs.lvgl.io/master/details/integration/driver/windows.html for more information.

Kenji Mouri

[sliang951753]

Hello,

The problem is if not using simulator mode, the WM_SIZE will update the "context->requested_display_resolution" to actual window client size. refer to (https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-size) , it says the LPARAM represents the windows client area width and height.
As we know, the window client size is normally smaller than the size when creating the window, it depends on the windows style. By using the Win32 API AdjustWindowRectEx , it is possible to get the actual required window size based on the desired client area size.

The reason why it works good in simulator mode is because the code will re-calculate the actual window size and the non-client area size will be taken into account.

I think we can fix it when handling the WM_CREATE message.

What do you think about ?

[MouriNaruto]

@sliang951753 It's actually the designed behavior for non-simulator mode because non-simulator mode is designed for developing Windows desktop applications with LVGL. So, you need to support auto-resizing if you want to develop Windows desktop applications with LVGL.

Kenji Mouri

[MouriNaruto]

@sliang951753 Also, for desktop application development, the resolution you set should be the window size instead of the window client area size for following the convention of other desktop UI infrastructures.

Kenji Mouri

[MouriNaruto]

@sliang951753 If you want to make your window client area size must be equal to the resolution you set. You should choose the simulator mode because it's designed for that.

Kenji Mouri

[MouriNaruto]

@sliang951753

I have created the simulator mode and application mode for LVGL v9 Windows backend because I think we should make LVGL have the ability to develop Windows desktop applications, but the classic simulator behavior also should be provided with the option enabled if users want to have.

Kenji Mouri

[sliang951753]

@MouriNaruto Sure, I understand your design.
My question is I need to make sure the client area is actually the size of the lvgl screen. No consideration of resizing window.
So, I think I should use the simulator mode. That's ok.

However, I don't want the window being scaled and the zoom level should be always 100%. Because if the window is scaled, all widgets and any drawing on this window will be blurred. That's not really good.

I saw the code will try to get the current monitor's DPI but simulator should keeps the same DPI as the real device. So that the UI appearance will be consistently on both PC and device.

What about we add customized DPI parameter in the create display function or other options to achieve this requirement ? If so, I thinks this would be perfect.

[MouriNaruto]

@sliang951753 zoom_level and allow_dpi_override will help you achieve that.

I saw the code will try to get the current monitor's DPI but simulator should keeps the same DPI as the real device. So that the UI appearance will be consistently on both PC and device.

If you use a tablet with a High DPI screen like the Surface Pro series, you will know why we need DPI scaling for content in the simulator mode by default. (I added that feature because some people said they cannot see the simulation result properly in high DPI environments.)

Kenji Mouri

[sliang951753]

@sliang951753 zoom_level and allow_dpi_override will help you achieve that.

I saw the code will try to get the current monitor's DPI but simulator should keeps the same DPI as the real device. So that the UI appearance will be consistently on both PC and device.

If you use a tablet with a High DPI screen like the Surface Pro series, you will know why we need DPI scaling for content in the simulator mode by default. (I added that feature because some people said they cannot see the simulation result properly in high DPI environments.)

Kenji Mouri

Of course, I can imagine that. But what about adding customized DPI to not following the monitor DPI settings as an extra option for this display driver. I think that wouldn't conflict with the original design concept but we might have an additional choice.

[MouriNaruto]

@sliang951753 zoom_level and allow_dpi_override will help you achieve that.

I saw the code will try to get the current monitor's DPI but simulator should keeps the same DPI as the real device. So that the UI appearance will be consistently on both PC and device.

If you use a tablet with a High DPI screen like the Surface Pro series, you will know why we need DPI scaling for content in the simulator mode by default. (I added that feature because some people said they cannot see the simulation result properly in high DPI environments.)
Kenji Mouri

Of course, I can imagine that. But what about adding customized DPI to not following the monitor DPI settings as an extra option for this display driver. I think that wouldn't conflict with the original design concept but we might have an additional choice.

You can set the zoom_level and allow_dpi_override parameters when calling lv_windows_create_display. These two are for achieving that goal.

Kenji Mouri

[sliang951753]

@sliang951753 zoom_level and allow_dpi_override will help you achieve that.

I saw the code will try to get the current monitor's DPI but simulator should keeps the same DPI as the real device. So that the UI appearance will be consistently on both PC and device.

If you use a tablet with a High DPI screen like the Surface Pro series, you will know why we need DPI scaling for content in the simulator mode by default. (I added that feature because some people said they cannot see the simulation result properly in high DPI environments.)
Kenji Mouri

Of course, I can imagine that. But what about adding customized DPI to not following the monitor DPI settings as an extra option for this display driver. I think that wouldn't conflict with the original design concept but we might have an additional choice.

You can set the zoom_level and allow_dpi_override parameters when calling lv_windows_create_display. These two are for achieving that goal.

Kenji Mouri

How can I determine the actual zoom level to achieve the desired resolution for different monitor DPI ?
The window is created inside the lv_windows_create_display() function, I cannot get the window handle before that.

[MouriNaruto]

You can disable the dpi override in simulator mode when creating LVGL display.

Kenji Mouri

[sliang951753]

You can disable the dpi override in simulator mode when creating LVGL display.

Kenji Mouri

That didn't work.
DPI override just pass the window dpi (retrieved from monitor) to LVGL. It doesn't change the window size scaling behavior.
Could you help to check this ?

[MouriNaruto]

Or you should change the zoom-level.

But I don't think we should keep 100% scaling all time in simulator mode because the PPI for desktop and your embedded device are different.

We keep the LVGL display resolution and dpi, but post-process for showing on desktop device screen properly is important.

Kenji Mouri

[MouriNaruto]

The goal of simulator mode is showing the UI layout properly on any desktop devices with specific LVGL display resolution and dpi.

Due to the desktop screen PPI and embedded device PPI are different in most of cases. We should not disable post-process scaling for simulator mode.

Kenji Mouri

[sliang951753]

Or you should change the zoom-level.

But I don't think we should keep 100% scaling all time in simulator mode because the PPI for desktop and your embedded device are different.

We keep the LVGL display resolution and dpi, but post-process for showing on desktop device screen properly is important.

Kenji Mouri

Of course we can't keep 100% scaling, otherwise it is not possible to achieve the desired Window size in simulator mode.
In my case, the zoom level has to be calculated dynamically according to the monitor DPI.
So, I'd like to discuss any possibility that makes the windows LVGL display driver more flexible and friendly to adapt different scenario.

[MouriNaruto]

In my case, the zoom level has to be calculated dynamically according to the monitor DPI.

Currently, the post-process DPI scaling is followed by Windows current monitor DPI, and keep the DPI setting in LVGL display to ensure the LVGL content layout is properly in the simulator mode.

If you want to have the more flexible scenario, please use the application mode. Don't be lazy for that.

Kenji Mouri

[MouriNaruto]

Currently, Windows backend doesn't support simulator mode without post-process DPI scaling. The simulator mode is not designed for more flexible scenario because it's only for simulation.

If you want to have the DPI scaling behavior like Windows desktop application, please don't be lazy, use the application mode instead.

Kenji Mouri

[vwheeler63]

@MouriNaruto Hi! Can you direct me on where to find out more about the "application mode" you are referring to?

Kind regards,
Vic

[MouriNaruto]

@MouriNaruto Hi! Can you direct me on where to find out more about the "application mode" you are referring to?

Kind regards, Vic

Read https://docs.lvgl.io/master/details/integration/driver/windows.html you will know what's the differences between two modes.

Kenji Mouri

[vwheeler63]

Read https://docs.lvgl.io/master/details/integration/driver/windows.html

Thank you!!