-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Debug tool to highlight unaligned cursor coordinates #4927
Milestone
Comments
This was referenced Aug 6, 2024
Merged
See my comment on #4928 (comment) about the need to decide what we want to align to (ui points of physical pixels) |
I think the correct thing to do here is to align ui points to integers in order to avoid rounding errors in width calculations and similar (see e.g. #5084). |
This was referenced Sep 25, 2024
emilk
added a commit
that referenced
this issue
Sep 25, 2024
* Closes #5106 * Closes #5084 Protect against rounding errors in egui layout code. Say the user asks to wrap at width 200.0. The text layout wraps, and reports that the final width was 196.0 points. This than trickles up the `Ui` chain and gets stored as the width for a tooltip (say). On the next frame, this is then set as the max width for the tooltip, and we end up calling the text layout code again, this time with a wrap width of 196.0. Except, somewhere in the `Ui` chain with added margins etc, a rounding error was introduced, so that we actually set a wrap-width of 195.9997 instead. Now the text that fit perfectly at 196.0 needs to wrap one word earlier, and so the text re-wraps and reports a new width of 185.0 points. And then the cycle continues. So this PR limits the text wrap-width to be an integer. Related issues: * #4927 * #4928 * #5163 --- Pleas test this @rustbasic
hacknus
pushed a commit
to hacknus/egui
that referenced
this issue
Oct 30, 2024
…k#5161) * Closes emilk#5106 * Closes emilk#5084 Protect against rounding errors in egui layout code. Say the user asks to wrap at width 200.0. The text layout wraps, and reports that the final width was 196.0 points. This than trickles up the `Ui` chain and gets stored as the width for a tooltip (say). On the next frame, this is then set as the max width for the tooltip, and we end up calling the text layout code again, this time with a wrap width of 196.0. Except, somewhere in the `Ui` chain with added margins etc, a rounding error was introduced, so that we actually set a wrap-width of 195.9997 instead. Now the text that fit perfectly at 196.0 needs to wrap one word earlier, and so the text re-wraps and reports a new width of 185.0 points. And then the cycle continues. So this PR limits the text wrap-width to be an integer. Related issues: * emilk#4927 * emilk#4928 * emilk#5163 --- Pleas test this @rustbasic
hacknus
pushed a commit
to hacknus/egui
that referenced
this issue
Oct 30, 2024
This tool highlights coordinates that are non-integer. * Closes emilk#4927 * Will be used for emilk#5163 This is disabled by default (even in debug builds), because so many widgets cause un-alignment currently.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When
ui.cursor()
is set to fractional coordinates that are not aligned to physical pixels, all sorts of visual issues ensue. For example,ui.button()
andui.selectable_*()
have their text oddly vertically aligned on the background (causing this).It would be very useful to have a tool that displays a big fat point whenever the cursor is unaligned, so we can easily spot the thing that created that misalignment in the first place.
The text was updated successfully, but these errors were encountered: