-
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
Add ui.align_cursor()
to for the cursor to be aligned with physical pixels
#4928
Comments
There are three alternatives:
I'd like to understand a bit more what the trade-offs are between these. Regardless of how/if we round widgets during layout, we still want to round some visual shapes to physical pixels to make them crisper (text, thin lines, etc). Rounding to physical pixelsSince we need to round some visual shapes to physical pixels anyway, always rounding to physical pixels may produce more even results. Rounding to logical ui pointsAll calculations are done in logical ui points, and so if we make them integers we prevent rounding errors.
I'd like a repro for this |
In light of the repro above, I believe rounding to physical pixels is what's needed, but, ultimately, whatever fixes this 😅 |
The problem there is the feathering (anti-aliasing) of the boxes. The easy fix there would be to always align boxes to the pixel grid, and turn of feathering for them. Related: |
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). The problem of rendering rectangles side-by-side without a seem is a purely visual one, and can be solved separately by one of these means:
I've opened two new issues for this: |
* 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
…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
Unaligned cursor lead to various visual glitches. It would be nice to have an API to "fix" the cursor position. This would avoid using code like this:
which is not robust to layout orientation and assumes 1:1 physical pixels.
Related:
The text was updated successfully, but these errors were encountered: