StyleBoxFlat aliasing looks blurry (regression between 3.2beta5 and 3.2beta6)

[Zylann]

Godot 3.2 beta5

Same stylebox, two versions.
Godot 3.2, beta5, worked fine:

Godot 3.2, beta6 and rc1:

Now it is blurry and has a line at the bottom.
Turning off antialiasing "fixes" it, but it looks worse than before.

Project:
TabContainerTheme.zip

It might have been broken in #34830, but if you look closely at the screenshots, only the inner parts were lacking anti-alias, while the outline parts were fine all along.

[akien-mga]

CC @pouleyKetchoupp

[pouleyKetchoupp]

@Zylann I think this use case can be fixed easily by adjusting the expand margin on either the tab itself or the panel. Although, in the current version it's limited because values are rounded to integers. So I've made a little fix in PR #35286 to allow finer tuning. It seems to look fine with this change after tweaking the following value in your script:
tab_panel.set_expand_margin_all(3.5)

Note: Border anti-aliasing size has slightly changed several times since 3.2 Beta 3 in order to fix some inconsistencies. This case with no border on one side wasn't working at all prior to 3.2 (see PR #34488), so there's no retro-compatibility issue here.

[Zylann]

Is there any way to make this more straightforward? Having to use a decimal number isn't obvious for the expected effect. On the contrary, I would have thought decimal numbers would cause that issue, not fix it (although as a coder I get that somehow, this is not true antialiasing (is it?) and compromises were made...).

With your fix and decimal expand margins, it fixes the horizontal line, but it still looks bad:

[pouleyKetchoupp]

Did you set anything in particular in order to get all the details, like a scale? I don't get the same results when rendering on my computer.

Here's how it renders with
tab_panel.set_expand_margin_individual(3, 3.5, 3, 3)

And can you try with these settings as well?
tab_fg.set_expand_margin_individual(0, 2, 0, -0.55)
tab_panel.set_expand_margin_individual(3, 3.2, 3, 3)

I feel like this is good enough. If you need to use larger size UI, you can try increasing the anti-aliasing size too.

[Zylann]

I did not scale anything in the project. I only upscaled the screenshots in an image editor using nearest-neighbor quality just so you don't have to squint to see the details.

Your screenshots look all blurry Oo

[pouleyKetchoupp]

@Zylann I'm not sure what is causing this difference in our screenshots when zoomed in, but let's focus on the different artefacts and how to solve them.

• Pixels on the left corner: could you try the two other sets of values I gave you in my last examples? I'd like to know if you're able to get rid of the issue. Also, could it be due to the nearest neighbor zoom in you do in your image editor?

• Thinner right border: from your screenshot, it seems it might be due to the next tab header slightly overlapping with the left one. Can you double check that by removing the other tab and see if the glitch is still present?

In general, I don't really understand what the problem is with decimal values to adjust UI settings (it just seems like it allows more control to me). But if we want to be able to setup everything with integer values only, then we'll need a deeper rework of how this stylebox aa works.

[Zylann]

Pixels on the left corner: could you try the two other sets of values I gave you in my last examples? I'd like to know if you're able to get rid of the issue.

With tab_panel.set_expand_margin_individual(3, 3.5, 3, 3)
Line disappeared and the top of the panel becomes solid, but its sides are blurry.

With

tab_fg.set_expand_margin_individual(0, 2, 0, -0.55)
tab_panel.set_expand_margin_individual(3, 3.2, 3, 3)

Line disappeared but the rest is still blurry.

Also, could it be due to the nearest neighbor zoom in you do in your image editor?

No, I scaled by 2x (integer amount) and keeping ratio.
You can check the theme from the editor: theme.zip

Thinner right border: from your screenshot, it seems it might be due to the next tab header slightly overlapping with the left one. Can you double check that by removing the other tab and see if the glitch is still present?

Yeah, I'm pretty sure it's the neighbor tab. Increasing margin does that.

In general, I don't really understand what the problem is with decimal values to adjust UI settings (it just seems like it allows more control to me).

I don't have a problem with decimal values, but the fact it becomes necessary to enter half-way numbers to obtain a non-blurry result. It's not intuitive, as I would have expected the opposite to happen: integer values should surely line up vertical and horizontal lines, while half-way values should produce blurry pixel lines.

After fiddling around, this is the best I could get:

tab_fg.set_expand_margin_individual(0.5, 2, -0.5, -0.55)
tab_panel.set_expand_margin_individual(3.4, 3.5, 3.4, 3)

if we want to be able to setup everything with integer values only, then we'll need a deeper rework of how this stylebox aa works.

As said above I'm not against decimals, but I feel we need true AA or a rework of the way it's done (if faked?). It takes time to fiddle around precise decimals until they all line up properly.

Note: to allow decimals in editor I had to change these lines:

	ADD_PROPERTYI(PropertyInfo(Variant::REAL, "expand_margin_left", PROPERTY_HINT_RANGE, "-10,2048,0.01"), "set_expand_margin", "get_expand_margin", MARGIN_LEFT);
	ADD_PROPERTYI(PropertyInfo(Variant::REAL, "expand_margin_right", PROPERTY_HINT_RANGE, "-10,2048,0.01"), "set_expand_margin", "get_expand_margin", MARGIN_RIGHT);
	ADD_PROPERTYI(PropertyInfo(Variant::REAL, "expand_margin_top", PROPERTY_HINT_RANGE, "-10,2048,0.01"), "set_expand_margin", "get_expand_margin", MARGIN_TOP);
	ADD_PROPERTYI(PropertyInfo(Variant::REAL, "expand_margin_bottom", PROPERTY_HINT_RANGE, "-10,2048,0.01"), "set_expand_margin", "get_expand_margin", MARGIN_BOTTOM);

[pouleyKetchoupp]

Ok, I think I understand now what you're trying to achieve. You would like border sides to be solid lines and only corners to use aa, right?

What you call blurry is actually the expected behavior from the way aa is implemented right now. It adds some alpha inside and outside all along the border to make things consistent in different cases (it's faked aa as you guessed).

In some cases, you get solid lines and I'm not sure why. Maybe the decimal values cause a one pixel line of alpha to be skipped depending on the resolution.

Also I've figured out why the rendering was blurry for me. My screen is high DPI, so I have to check the project option "Allow HighDpi" if I want to keep the high resolution. It makes UI very small instead of the blurry scale up I had before.

So here's my result with your latest settings on my screen:
(I'm scaling it up by 2x in an external editor like you did)

What I can propose is to look again at the aa code and see if I can make it so border sides would be solid like you expect. I think it does make sense since we probably need only the corners to be anti-aliased. But there are lots of different combinations to handle, I'm not sure what other problems I might hit. I'll let you know.

Note: The missing sliders for decimal values are addressed in PR #35287.

[Calinou]

What's the status on this as of 3.2.3? Is this reproducible in the master branch?

[Zylann]

Yes it's still there in 3.2.3. (someone had the same problem on Discord today)

[Calinou]

I can still reproduce this in 4.0.dev.custom_build [b5b633f].

[Nukiloco]

I think the issue with AA should be fixed rather than trying to bypass the issue. Either that or there should be new properties that allow certain sides of borders to be blurry and sharp.

[Calinou]

I think the issue with AA should be fixed rather than trying to bypass the issue. Either that or there should be new properties that allow certain sides of borders to be blurry and sharp.

One way to fix this would be to change StyleBoxFlat's antialiased property to use an enum instead, with three possible values:

• Disabled
• Crisp (what we had in 3.1.x)
  • Crisp, but does not handle rotated StyleBoxes. This is what the new default project theme would use.
• Smooth (what we have now)
  • Blurry, but handles rotated StyleBoxes.

[pouleyKetchoupp]

@Calinou That sounds like a great idea! We could do that for 3.x since proper antialiasing will be probably supported only in 4.x.

[Calinou]

@Calinou That sounds like a great idea! We could do that for 3.x since proper antialiasing will be probably supported only in 4.x.

Switching to an enum for the antialiased property will break compatibility with existing projects, so we'll have to add a second boolean property in 3.x instead.

Also, I doubt 2D MSAA will be supported in time for 4.0's release, so this is still worth implementing in master. Not to mention that MSAA gets expensive at high resolutions, even in 2D.

[pouleyKetchoupp]

Switching to an enum for the antialiased property will break compatibility with existing projects, so we'll have to add a second boolean property in 3.x instead.

@Calinou Couldn't we handle compatibility in 3.x by overriding the property _set function and set a specific value when antialiased is true? And then if it's still needed on master it can be done with compatibility breaking to make the code cleaner.