Fix DPI Scaling Issues #86
Conversation
Path of Building’s Lua UI always works in “virtual” coordinates, while the renderer operates in physical pixels. After enabling DPI scaling, the text renderer and the Lua-side layout logic started disagreeing about where a glyph ends. The mismatched math had a couple of side effects noticeable at 125 %+ Windows scaling:
Extends the scaling feature with the ability to set the scaling value from within PoB and also have it update in real-time when a user changes the option so they don't need to restart the app
Adds a setting in the options menu that allows the user to override the scaling PoB uses incase they don't want it to look the same as their windows scaling Relies on PathOfBuildingCommunity/PathOfBuilding-SimpleGraphic#86
There was a problem hiding this comment.
Looks like search text disappeared in the BuildList and TreeTab search bars at greater than 100% scaling.
Edit: Any single-line EditControl whose height isn't 18 disappears at 125% scaling. I believe this is because 18 - 4 = textHeight, and textHeight * 1.25 gets rounded back to 18 to get a proper font size that fits in the box height.
There was a problem hiding this comment.
I'll drop the diff here for ui_api.cpp here instead of adding suggestions to the whole file like I did for r_font.cpp. Other than my comments this looks pretty good overall though. I'm guessing you had to use ceil instead of floor because it was already doing that truncation before when converting to ints? Similar question to if round worked, but clearly it works well in-app, so I won't complain
When a dropdown row, edit box, or the build-name strip requested a 14 px logical height, the UI API scaled it to 17.5 px at 125 %, then truncated it to 17 px before passing it to the renderer. Meanwhile, `DrawString` was rounding up to an 18 px glyph, so the entire quad was clipped away.
The first glyph was not being snapped to a pixel so if scaling put the pixel coordinate at a fractional value it would look blurry
Changes some of the type declarations to use static_cast
2 participants
Path of Building’s Lua UI always works in “virtual” coordinates, while the renderer operates in physical pixels. After enabling DPI scaling, the text renderer and the Lua-side layout logic started disagreeing about where a glyph ends. The mismatched math had a couple of side effects noticeable at 125 %+ Windows scaling:
StringCursorInternaland the Lua helperDrawStringCursorIndexwere still working in integers, so they rounded positions down, re-applied the DPI scale, and lost the same fraction of a pixel. Repeatedly stepping through characters amplified that rounding error until the caret visibly drifted away from the glyphs.DrawStringWidthwas dividing by the DPI factor before returning, meaning Lua got a value in logical units while everything else was doing manual scaling. In some cases (selections, cursor hit testing) that measurement was multiplied by the DPI factor again, exaggerating the offset on fractional scales.Also added logic in second commit for PoB to be able to override the scaling value in-case people want it to be different from their windows setting
Added logic in the 4th commit to fix the rendering of textboxes and dropdowns where the renderer and
DrawStringfunctions were not using the same rounding so would cause issuesAdd logic in the 5th commit to snap the start of strings to a full pixel otherwise the first glyph could land on a fractional value and cause it to be blurry as it would use bilinear filtering