-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align TextBuilder
characters by their baselines during addition/removal
#4774
Align TextBuilder
characters by their baselines during addition/removal
#4774
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks solid. As I mentioned in discord, we probably want to rework TextBuilder
altogether to improve performance - having everything done in-line in AddCharacter
/RemoveCharacter
is not good, but that goes for everything else as well.
this is missing a breaking change clause for the updated method signature, will add. |
Actually there's quite a few changes, just going to leave it. All mostly internal stuff so I don't think too many people will be hit by it. |
Previously characters were implicitly aligned using their
YOffset
s, and that works when only one font is used, but not when more than one font gets used inside oneSpriteText
/TextBuilder
.This PR aims to resolve the "multiple fonts" case by offsetting their
DrawRectangle
s based on the difference between theBaseline
of the new character and the previous characters.I've worked on this initially so that font-mixed sprite texts with #3271 don't look badly misaligned (as I noticed after implementing #3271), but apparently, there are already alignment improvements osu!-side with this PR alone (although slightly unnoticable):
Before:
After:
(notice
(TV Size)
aligned correctly with the other glyphs)I have added in-depth test coverage in
TextBuilderTest
which had the perfect setup for having so, with all possible scenarios I can think of.Along with test coverage, I've also added a benchmark including the regular "no baseline adjustment" cases, and "one baseline adjustment every 10 characters" case, and the results seem reasonable.
I can see this being further optimised by offseting new characters to negative
X/Y
s rather than offsetting all the other previous characters in the line, but that might be a bit complicated to deal with in theSpriteText_DrawNode
(especially given thatTextBuilder
can have multiple lines), therefore I've went with the simplest way of for looping all characters in the line for now.