Skip to content

Add StyleBoxFlat anti-aliasing force - #123529

Open
Joy-less wants to merge 1 commit into
godotengine:masterfrom
Joy-less:add-StyleBoxFlat-anti-aliasing-force
Open

Joy-less wants to merge 1 commit into
godotengine:masterfrom
Joy-less:add-StyleBoxFlat-anti-aliasing-force

Conversation

@Joy-less

Copy link
Copy Markdown
Contributor

What problem(s) does this PR solve?

Screenshots

The force property in the inspector when anti-aliasing is disabled:

image

The force property in the inspector when anti-aliasing is enabled:

image

The panel when anti-aliasing is enabled and force is disabled:

image

The panel when anti-aliasing is enabled and force is enabled:

image

Additional information

There are several ways I can think of to achieve the same thing, but this way seems the cleanest and simplest.

No AI used.

int corner_detail = 8;
int shadow_size = 0;
Point2 shadow_offset;
bool anti_aliased_force = false;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be:

Suggested change
bool anti_aliased_force = false;
bool force_anti_aliased = false;

For the methods as well

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trouble is, it wouldn't start with anti_aliasing_ which means it wouldn't work inside this group.

image

Unless you mean the internal variables should be force_anti_aliased but the exposed variable should be anti_aliasing_force.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that it is odd English, but for the property it can be fine but the methods should be changed at least they are fully invalid

@Calinou Calinou added this to the 4.x milestone Sep 15, 2026
@Samvkes

Samvkes commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

I think some version of this is needed, but I think the cleaner way would be to only apply the aa when needed, ie when the panel is rotated.
Doing that is not really possible currently, so instead we should maybe consider completely removing the no-rounding optimization and just always run aa when it’s toggled on.

This “force” attribute only makes sense if you have a detailed understanding of the sbf implementation, otherwise it just adds on another layer of confusion. (And if we’d have to add this I’d honestly prefer a project-level setting instead of doing it per stylebox.)

(Alternatively, having a toggle called “only apply when corners are rounded” that’s on by default, would be less confusing (but still messy))

@Joy-less

Copy link
Copy Markdown
Contributor Author

I think some version of this is needed, but I think the cleaner way would be to only apply the aa when needed, ie when the panel is rotated.

I did consider this, but like you said it's not necessarily possible. Also, it would mean you still couldn't have antialiasing when there is no rotation (sometimes useful if you have a panel with rounded corners and a panel with sharp corners next to each other, and you want them to look consistent. Or if you are going to tween the rotation from zero and don't want it to suddenly become blurry.)

Doing that is not really possible currently, so instead we should maybe consider completely removing the no-rounding optimization and just always run aa when it’s toggled on.

I think they already rejected this, because it would be a breaking change, and since antialiasing is on by default, it would cause performance reductions and blurriness in existing projects.

(Alternatively, having a toggle called “only apply when corners are rounded” that’s on by default, would be less confusing (but still messy))

It may indeed be better to be reversed, but it would have to be something like anti_aliasing_only_when_no_rounded_corners_and_no_skew. The conditions may also change in the future.

@Samvkes

Samvkes commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

I did consider this, but like you said it's not necessarily possible. Also, it would mean you still couldn't have antialiasing when there is no rotation (sometimes useful if you have a panel with rounded corners and a panel with sharp corners next to each other, and you want them to look consistent. Or if you are going to tween the rotation from zero and don't want it to suddenly become blurry.)

...
I think they already rejected this, because it would be a breaking change, and since antialiasing is on by default, it would cause performance reductions and blurriness in existing projects.

I hadn't considered that there is a visible difference between un-rotated, un-skewed panels with straight corners when aa is applied vs not. I guess that would make it a breaking change. It's a pity though, because Imo it is one of the things that makes SBF feel kinda inconsistent.

It may indeed be better to be reversed, but it would have to be something like anti_aliasing_only_when_no_rounded_corners_and_no_skew. The conditions may also change in the future.

Maybe we could just do "Optimize" or something similar? With a warning and explanation in the tooltip?
(thinking more about this, I guess optimize is basically as cryptic as "Force". There must be a way to phrase it that is both compact and clear)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StyleBoxFlat antialiasing not applied with corner radius 0

4 participants