Skip to content
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

fix text legibility with subpixel vertex position #151

Closed

Conversation

msparkles
Copy link
Contributor

No description provided.

Copy link
Member

@LPGhatguy LPGhatguy left a comment

Choose a reason for hiding this comment

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

Thank you for finding a fix! I've still gotta clone this and try it out.

I left a couple comments about the implementation.

@@ -203,6 +204,10 @@ impl PaintDom {
let mut pos = vertex.position * self.scale_factor;
pos += self.unscaled_viewport.pos();
pos /= self.surface_size;
if mesh.pipeline == Pipeline::Text {
Copy link
Member

Choose a reason for hiding this comment

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

Why does this only apply to the text pipeline? Wouldn't other textures also be affected here?

If only text is affected, can we round the vertex positions in text_renderer instead of special casing the pipeline here? I think this is too late in the rendering pipeline to have code that specializes based on the pipeline.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason it's in this stage of the pipeline is that during it we also multiply it by the scale factor, and if we remember correctly, RoundRect depends on this subpixel position to behave correctly

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We might need to figure out how to move the scale factor multiplication out of the pipeline if we wanted to resolve this

Copy link
Member

Choose a reason for hiding this comment

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

Ah, gotcha. We need to round to the nearest physical pixel, but components output vertices in logical pixels, where it's too early in the pipeline to round.

I'd be surprised if any components relied on sub-physical-pixel vertex positions! If we can find a widget in the tree that gets worse without subpixel positions, I'm sold.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For rounded rect:
first: rounded
second: unrounded

we think this issue is even more pronounced with a non-integer scale factor

image
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

image

rounded, with a scale factor of 1.25

@@ -203,6 +204,10 @@ impl PaintDom {
let mut pos = vertex.position * self.scale_factor;
pos += self.unscaled_viewport.pos();
pos /= self.surface_size;
if mesh.pipeline == Pipeline::Text {
pos = (pos * self.surface_size).round() / self.surface_size;
Copy link
Member

Choose a reason for hiding this comment

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

Since we divide by surface_size above, can we move this up statement a line and just write:

pos = pos.round();

Copy link
Member

Choose a reason for hiding this comment

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

To be more specific, this code:

pos /= self.surface_size;
if mesh.pipeline == Pipeline::Text {
    pos = (pos * self.surface_size).round() / self.surface_size;
}

would behave identically to this code:

if mesh.pipeline == Pipeline::Text {
    pos = pos.round();
}
pos /= self.surface_size;

@LPGhatguy
Copy link
Member

When you file PRs in the future, feel free to use GitHub's "closing keywords" to make it so your PR automatically closes the issue that it fixes. For example, you can write:

Closes #1.

and that will link your PR up with that issue and close it once I merge it.

@LPGhatguy
Copy link
Member

I did kind of a roundabout squash merge here to get around the issue described here because I don't have write access to this PR branch: https://github.com/orgs/community/discussions/5634

You've been credited on that commit the same way that GitHub's automerge would've credited you, I think!

I'm going to close this PR since the code made it in.

@LPGhatguy LPGhatguy closed this May 3, 2024
@msparkles msparkles deleted the fix/text-legibility branch May 3, 2024 03:08
@msparkles msparkles mentioned this pull request Jun 30, 2024
Uriopass pushed a commit to Uriopass/yakui that referenced this pull request Jun 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants