Fill unpainted region in Window in win32 #62

[amartya4256]

This commit contributes to filling the unpainted region unoccupied by the menu bar and the client area in a window, including the MenuItem hover overlay remains in the area after hovering over them as sometimes MenuItems have their height more than the height of the menu bar, leading to painting in the unmanaged region - hence, contributing to an artifact line.

How to test:

• Have your primary monitor at 250% and secondary at 125%.
• Start the IDE and move to 125% monitor.

**Undesired Behaviour: ** There's an artifact line between the menu bar and the client area inside the window of the IDE.

**Expected Behaviour: ** There should not be any region in the Window which remains unpainted leading to adverse effects / artifact lines.

contributes to
#62 and #127

[github-actions]

Test Results

   545 files  +  247     545 suites  +247   28m 24s ⏱️ + 23m 26s
 4 369 tests +  306   4 357 ✅ +  310   12 💤  -  4  0 ❌ ±0 
16 624 runs  +8 661  16 515 ✅ +8 584  109 💤 +77  0 ❌ ±0 

Results for commit b81ece1. ± Comparison against base commit 6e865bc.

♻️ This comment has been updated with latest results.

[BeckerWdf]

can you please highlight the unwanted line in you screenshots?

[amartya4256]

can you please highlight the unwanted line in you screenshots?

It is already there in the first picture - between the menu bar and the tool bar.

[BeckerWdf]

can you please highlight the unwanted line in you screenshots?

It is already there in the first picture - between the menu bar and the tool bar.

The black line?

[amartya4256]

can you please highlight the unwanted line in you screenshots?

It is already there in the first picture - between the menu bar and the tool bar.

The black line?

Yes

[HeikoKlare]

I have tested the proposal with different zoom factors and found the region that is erroneously not automatically refreshed to be properly covered/calculated by the fix. For the different scenarios, I have compared a client from existing code to one started from the changed code.

What I found is that in the area between menu bar and tool bar, now always a white line is painted. This even happens in a pure 100% zoom setup. Before this change, there was a grayish-colored line between menu bar and tool bar. In the following screenshot you see the existing appearance at the top and the modified one at the bottom:

Is there a possibility to use a "proper" (i.e., the previously used) color for painting that area to preserve the existing look & feel?

[amartya4256]

It should be possible. And ofcourse it is white because it always picks the color white using the flag I have used in the PR. I need to have a look and see what how I can achieve filling a custom color.

[amartya4256]

The grey line seems to be drawn and managed by windows. In all the cases this line is drawn in the gap between the menu bar and the client area. However, in some scenarios this line is not drawn for some reason and the artifact line is present. It happens for the scenario mentioned in the PR description above. After looking into it, I derived following points:

1. The color of the grey line is unknown since it is completely managed by Windows.
2. I tried drawing it with some random grey color and the result was not good since the artifact line can also appear on the right side of the bar or on top of the bar - in case of dark theme. The only way to make it consistent is to blend it with the background color of the menu bar itself. Otherwise, We need to find the rectangle to the right side of the menu bar and fill it white explicitly, which is a dirty approach.

However, with this PR, it will be consistently white on all the monitors. Considering we don't have a straightforward cleaner approach to get the grey line only on the bottom, it is still an improvement over the artifact line. So, my proposal would be to move forward with this solution and then try to find out if we can reproduce the grey line.

[HeikoKlare]

In case we do not see an alternative right now, I would say we should just give it a try with this approach and see if anyone complains about the slightly changed (but then consistent) look and feel. This will not break anything, so we can just wait if feedback pops up and in that case adapt or revert the change.