Improve CTabFolder highlight appearance on higher zooms

[HeikoKlare]

The highlight of CTabFolders implemented in CTabRendering does not properly deal with higher zooms on Windows. The outline of the tabs is drawn with a width of one pixel whereas the highlight has an offset of one point, producing a gap at higher zooms. In addition, the highlight for rounded tabs exceeds the intended bounds.

This change adapts the rendering as follows:

• When the highlight is drawn rounded at the top, the shape of the outline is taken and adapted to the intended highlight height to draw the highlight.
• In all other cases the highlight is drawn as a simple line of according width with an offset of half the line width with respect to its bounds. To compensate for the 1px border that is drawn on top of the highlight when it is placed at the top of a tab, another line of according size is drawn next to the highlight to make its height fit again.

One problem that is not solved by this are inconsistent heights of the highlights when using a CTabFolder with headers being placed at the bottom at 125% and 175%. The root cause is an already misplaced/miscalculated header region, at it exceeds the intended size to the bottom. So in order to improve that behavior, the header region calculation has to be fixed.

This is a proposal to overcome the current limitations of:

• Adjust selection bounds for CTabRenderring #3533

How it looks

Windows

CTabFolders with headers on top:

CTabFolders with headers at top:

Linux

150% used fractional scaling mode, which is why the screenshot has the same size as 200% (the OS scales down a faked 200% canvas):

MacOS

[github-actions]

Test Results

 3 015 files  ±0   3 015 suites  ±0   2h 4m 39s ⏱️ - 2m 27s
 8 258 tests ±0   8 010 ✅ ±0  248 💤 ±0  0 ❌ ±0 
23 598 runs  ±0  22 807 ✅ ±0  791 💤 ±0  0 ❌ ±0 

Results for commit 92aa308. ± Comparison against base commit e81ba1c.

♻️ This comment has been updated with latest results.

[ShahzaibIbrahim]

At 100%, there is a behavior change from previous implementation:

The bottom highlight has a gap from bottom, the same issue that was mentioned here: #3533 (review)

Left: Current implementation
Right: Your change.

At 250%: I see highlight color bleeding out to left tab when hovered. See, (its a gif, please open it in other tab to see it running)

[HeikoKlare]

At 100%, there is a behavior change from previous implementation:

The bottom highlight has a gap from bottom, the same issue that was mentioned here: #3533 (review)

It's interesting that I did not have that when testing (as can be seen in my screenshots). I don't understand why, as I can also reproduce it.

@ShahzaibIbrahim can you maybe update and simplify your PR to support the onBottom case based on insights from this PR? Maybe just adding the -1 back would already solve the placement issue you mentioned.