Adjust selection bounds for CTabRenderring

[ShahzaibIbrahim]

Selected tabs highlight look slightly off and more noticeable when zoom is not 100%. These adjusted value shows no gaps from top and better aligned highlights for tabs (Theme is enabled)

Results:

This is the expected highlight size chart for different zooms

Highlight Tab	Formula	In Points	100	150	175
Square Top	Round(pts * (zoom / 100) - 1(outline))	3pt	3	4	4
Bottom	Round(pts * (zoom / 100))	2pt	3	4	5
Rounded	Round(pts * (zoom / 100))	2pt	2	3	4

[github-actions]

Test Results

 3 015 files  ±0   3 015 suites  ±0   2h 10m 31s ⏱️ - 11m 10s
 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 b088af9. ± Comparison against base commit a501e9a.

♻️ This comment has been updated with latest results.

[HeikoKlare]

With this change, the highlight line looks very thin (on 100%):

This is how it used to look:

[ShahzaibIbrahim]

@HeikoKlare I found the problem. Here were drawing the tab from (0,0) pixel but still using initial item location (1,1) and hence the gap was visible. I also updated the height to 3 when we draw from (0,0) so we have enough height for the selection marker.

The code that caused the gap:
https://github.com/vi-eclipse/eclipse.platform.ui/blob/8be04038fd7a1dd5cf4f7972e7813d0925181315/bundles/org.eclipse.e4.ui.workbench.renderers.swt/src/org/eclipse/e4/ui/workbench/renderers/swt/CTabRendering.java#L572C2-L577

[HeikoKlare]

The appearance is in my opinion much better than before. I have some questions/remarks on the current propose.
And the appearance with round tabs now became worse (than it already was before):

We may probably do something similar than in SWT to draw a proper shape. The current adjustments by 1 point based on cornerSize do not look sufficient.

[ShahzaibIbrahim]

The appearance is in my opinion much better than before. I have some questions/remarks on the current propose. And the appearance with round tabs now became worse (than it already was before):

We may probably do something similar than in SWT to draw a proper shape. The current adjustments by 1 point based on cornerSize do not look sufficient.

While I agree the rounded tabs should be adapted. But I wouldn't say it looks "worse" than master. Here's the SS comparing this PR and master state.

I would suggest that we fix the shape in another PR. This PR fixes the gap that we had from the top.

[amartya4256]

I pulled the branch and ran it on 250%. This is how it looks for me:

I can see a small gap in the left and at the top. Is it supposed to look like this?

[HeikoKlare]

I can see a small gap in the left and at the top. Is it supposed to look like this?

No, it should be fully aligned at the top, left and right without any gaps at every zoom.

[ShahzaibIbrahim]

I pulled the branch and ran it on 250%. This is how it looks for me:

I can see a small gap in the left and at the top. Is it supposed to look like this?

Are you sure you checked out master-517 from platform.ui? We also have master-517 for SWT. I checked again and there is no gap for the highlight.

[HeikoKlare]

@amartya4256 can you please retest this? Unfortunately, I have currently monitor available that I can set to 250%. Everything up to 225% looks fine to me.

[HeikoKlare]

I would suggest that we fix the shape in another PR. This PR fixes the gap that we had from the top.

@ShahzaibIbrahim But maybe that would require another readaptation of the calculations. Shouldn't we just fix it right away? Then it would also make more sense to take into account the outlineBoundsForOutline as those are used by the calculations for the (potentially rounded) borders.

[ShahzaibIbrahim]

I would suggest that we fix the shape in another PR. This PR fixes the gap that we had from the top.

@ShahzaibIbrahim But maybe that would require another readaptation of the calculations. Shouldn't we just fix it right away? Then it would also make more sense to take into account the outlineBoundsForOutline as those are used by the calculations for the (potentially rounded) borders.

I have added a commit to put highlight on rounded tabs. Although it looks big jagged as original one (non-selected rounded tabs) also bit jagged. I have reused the shape.

Here's the comparison of the selected and unselected tabs:

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF

Warning

🚧 This PR cannot be modified by maintainers because edits are disabled or it is created from an organization repository. To obtain the required changes apply the git patch manually as an additional commit.

Git patch

From d1e7f2d1fabc7ac074af0a8ef8219a8b09b14361 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Mon, 15 Dec 2025 12:58:37 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
index 249542c521..ca4f9ad426 100644
--- a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.e4.ui.workbench.renderers.swt;singleton:=true
-Bundle-Version: 0.16.1000.qualifier
+Bundle-Version: 0.16.1100.qualifier
 Bundle-Name: %pluginName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.52.0

Further information are available in Common Build Issues - Missing version increments.

[ShahzaibIbrahim]

After latest adaptation, there is no more "Bleeding" on the very left and right. The selection highlight looks fine to me in different zoom levels. Also addressed the comments from you @HeikoKlare. Let me know if I miss something.

[HeikoKlare]

We seem to be coming closer. The code became much simpler and many scenarios now look good.
But with rounded corner, the highlight is still far too large. At 150%, it looks like this (compare to the "correct" hight for the non-focused "problem" view below):

When reducing the hight by 1, I see the rendering artifacts mentioned before again.
The screenshots in the previous post seem to be taken with some custom auto-scaling settings. The tab icons are not scaled according to the text, so probably monitor-specific scaling is disabled or some custom auto-scale configuration is active.

[ShahzaibIbrahim]

We seem to be coming closer. The code became much simpler and many scenarios now look good. But with rounded corner, the highlight is still far too large. At 150%, it looks like this (compare to the "correct" hight for the non-focused "problem" view below):

I reduced the height by 1 and fixed the bleeding and this is how it looks now. For me its too small now. But if it feels okay to you I can push the changes.

[ShahzaibIbrahim]

As discussed earlier, the highlight height for the curved and non-curved tab folders should be same. I have adjusted the height now. This is the final result.

[HeikoKlare]

I looks almost fine now. But the lines still do not have the same height, such that the highlight bar with rounded corners appear a bit too thick and prominent. These are the heights I get:

• 100%: round corners 3px, square corners 2px
• 175%: round corners 5px, square corners 4px

Here is the comparison of the highlight at 100% with round corners before (top) and after (bottom) this change:

The overall appearance is definitely much better, but the line is thicker now.

[akoch-yatta]

I still see a difference in upper and lower height of the highlight in 150%

[ShahzaibIbrahim]

I still see a difference in upper and lower height of the highlight in 150%

I tried with power toys and the lower highlight and upper highlight both are 3px each.

[akoch-yatta]

Just measured it in my Runtime, the lower one is 3px, the upper one is 4px

Doesn't that make sense as final int highlightHeight = 1 + (superimposeKeylineOutline && highlightOnTop ? OUTER_KEYLINE_WIDTH : 0); does draw the rectangle with a different height because of that?

[HeikoKlare]

Just measured it in my Runtime, the lower one is 3px, the upper one is 4px

I can confirm this observation.

[arunjose696]

I have tested with the new changes, I can observe the lower one and upper one are now both 3px, but I observe a different issue. The boarder that passes through the bottom highlight are now missing

This change

Master

[ShahzaibIbrahim]

I have tested with the new changes, I can observe the lower one and upper one are now both 3px, but I observe a different issue. The boarder that passes through the bottom highlight are now missing

It's resolved now.

[arunjose696]

Approving this as the changes look fine on all tested zooms

[HeikoKlare]

This PR currently breaks some existing behavior (also see the detailed comment).

The highlights are misplaced (also see the detailed comment). This can directly be seen at the highlights displayed at the bottom, which are too small now:

This is how they used to look like:

[HeikoKlare]

I was wondering why the outline is now drawn first instead of after painting the highlight.
When taking a look at how it looks, it turns out that this PR now changes the placement of the highlight, such that it overwrites the outline:

While you do not notice that much with the default gray outline, this would look really odd if you have a colored outline. Since the gc.setForeground(tabOutlineColor) call has been accidentally removed, you will not notice as the color is simply missing.

Please move this call back or ensure by any other means that the outline remains properly drawn.

[ShahzaibIbrahim]

I have reverted the outline to its original position. However as discussed to accommodate outline we had to increase the highlight height for squared tabs. Here is how it compares to rounded and bottom tabs.

This is the expected highlight size chart for different zooms

Highlight Tab	Formula	In Points	100	150	175
Square Top	Round(pts * (zoom / 100) - 1(outline))	3pt	3	4	4
Bottom	Round(pts * (zoom / 100))	2pt	2	3	4
Rounded	Round(pts * (zoom / 100))	2pt	2	3	4

[HeikoKlare]

Almost everything looks fine now. But the highlight bar is misplaced when shown at the bottom and using round tabs (e.g., at 150%):

[ShahzaibIbrahim]

Almost everything looks fine now. But the highlight bar is misplaced when shown at the bottom and using round tabs (e.g., at 150%):

You're right. The bottom selection highlight shouldn't care if they are rounded or squared tabs. I have fixed it.

[HeikoKlare]

Now with the latest changes it is too small again when placed at the bottom. In this screenshot, the left is the state now and the right is the state with this PR (at 150% zoom):

This is also somehow expected as the offset calculation used bounds.height - (highlightHeight - 1) before andnow uses bounds.height - (highlightHeight).

May I also ask to test every combination (rounded/square, bottom/top, different zooms) for the next review iteration yourself first?

[ShahzaibIbrahim]

Now with the latest changes it is too small again when placed at the bottom. In this screenshot, the left is the state now and the right is the state with this PR (at 150% zoom):

This is also somehow expected as the offset calculation used bounds.height - (highlightHeight - 1) before andnow uses bounds.height - (highlightHeight).

If you look the screenshot, the current state highlight is below the outline

And the after change, the size is as per the chart that I mentioned here in the comment (i.e. 3px at 150%): #3533 (comment)

[HeikoKlare]

Okay, I see the misplacement in the existing behavior. But it's misplaced with this PR as well, just in the opposite direction (it is placed too high instead too low). Note that the zoom I posted (150%) seems to actually have been incorrect for the screenshot. It must have been taken at 125%.

And the after change, the size is as per the chart that I mentioned here in the comment (i.e. 3px at 150%): #3533 (comment)

So why do we do it like that? While the highlight at the bottom was just misplaced before (at 125%), it is now misplaced and inconsistent to other highlights being show at the top (if not using round tabs, which is rather uncommon). Couldn't we draw an additional line (in addition to filling the rect) to compensate for the rounding error here? Since the outline is drawn at the y coordinate where the highlight is missing at 125%, it might be possible to compensate with that.

[ShahzaibIbrahim]

Okay, I see the misplacement in the existing behavior. But it's misplaced with this PR as well, just in the opposite direction (it is placed too high instead too low). Note that the zoom I posted (150%) seems to actually have been incorrect for the screenshot. It must have been taken at 125%.

And the after change, the size is as per the chart that I mentioned here in the comment (i.e. 3px at 150%): #3533 (comment)

So why do we do it like that? While the highlight at the bottom was just misplaced before (at 125%), it is now misplaced and inconsistent to other highlights being show at the top (if not using round tabs, which is rather uncommon). Couldn't we draw an additional line (in addition to filling the rect) to compensate for the rounding error here? Since the outline is drawn at the y coordinate where the highlight is missing at 125%, it might be possible to compensate with that.

I have now drawn a line on very bottom (the filler space), although It will make it look slightly darker (I have updated the values in the chart, see description). Also I have tested on every zoom which to me looks good now. The highlight is right on the line. The latest push doesn't affect top highlights (square or rounded). Attaching the screenshot for bottom highlight for all the zoom:

Bottom Highlight with rounded tabs on top