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

console.lua: improve the hovered item calculation #15673

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

guidocella
Copy link
Contributor

@guidocella guidocella commented Jan 10, 2025

console.lua: improve the hovered item calculation

Currently determine_hovered_item() assumes that each item is opts.font_size pixels tall, which usually works well. This breaks with fonts that get drawn taller than that, such as Japanese text, which makes the calculation inaccurate for the top items and clips the counter. A couple of users reported that it is inaccurate for them for the top items even with ASCII characters in track selectors, presumably because the circles are taken from a different font and make all lines taller.

To fix this place each selectable item in its own ASS event positioned like determine_hovered_item() expects.

This should fix @sfan5's issue.

Rename lines_max to max_lines which is the name used in other functions,
and inline the log_messages variable because its name was confusing.

The math.max(0, lines_max) call was not necessary because console
doesn't crash with 0 or negative max lines.
This deduplicates the calculation of the y position by assigning it to a
y variable, which will also be used in the next commit. margin_x is also
renamed to x for consistency.
@guidocella guidocella changed the title console.lua: improved the hovered item calculation console.lua: improve the hovered item calculation Jan 10, 2025
@sfan5 sfan5 self-requested a review January 10, 2025 12:06
Copy link

github-actions bot commented Jan 10, 2025

Download the artifacts for this pull request:

Windows
macOS

Currently determine_hovered_item() assumes that each item is
opts.font_size pixels tall, which usually works well. This breaks with
fonts that get drawn taller than that, such as Japanese text, which
makes the calculation inaccurate for the top items and clips the
counter. A couple of users reported that it is inaccurate for them for
the top items even with ASCII characters in track selectors, presumably
because the circles are taken from a different font and make all lines
taller.

To fix this place each selectable item in its own ASS event positioned
like determine_hovered_item() expects.
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.

1 participant