Fix(Damage Meter): bars rendering at different sizes - #2051
Open
JuJuFX-dev wants to merge 2 commits into
Open
Conversation
barHeight, shBarHeight and the spell history iconSize were converted to a physical pixel count (value * PP.mult), while the window width, fonts and bar spacing are coordinate units. At any UI scale other than pixel-perfect the bars drifted out of proportion with their own window, so a shared profile rendered visibly thinner or thicker bars depending on the receiving user's resolution and UI scale. Treat these values as coordinates and only snap them to the pixel grid. RowMetrics keeps both terms on the frame's effective-scale grid, and its fourth return value is still one physical pixel, so no call site changes. Line thicknesses (borders, dividers, the thin line texture) stay physical.
Add a one-time global migration that multiplies barHeight and the Spell History shBarHeight/iconSize by the old physical-pixel factor (768 / screen height / ppUIScale), so every profile that exists at update time keeps its exact rendered size. Pixel-perfect setups (factor within 1%) are left untouched. Global scope keeps imports out of it: profile-scope stamps ride exports, so an old string would be converted with the recipient's factor and freeze their UI scale into it. After this ran, imported values are read as UI units. A per-profile stamp keeps the body idempotent if a full-account import replaces the global migration flags.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bugreport: https://discord.com/channels/585577383847788554/1547524557643186178
What does this PR do?
Fixes Damage Meters bars rendering at different sizes for different users when a profile is shared. Bar Height (and the Spell History bar height and icon size) was converted to a physical pixel count (
value * PP.mult), while everything else in the window (width, fonts, bar spacing) is in UI units. At any UI scale other than pixel-perfect, the bars therefore drifted out of proportion with their own window, so the same exported value looked thinner or thicker depending on the receiving user's resolution and UI scale (4K on the auto scale is affected too, since the scale clamps at 0.4).These values are now treated as UI units and only snapped to the pixel grid, like the window width.
RowMetricskeeps height and spacing on the same effective-scale grid, so the even spacing from the previous fix is preserved and no call site changes. Line thicknesses (borders, dividers, the thin-line texture) stay physical on purpose.To avoid any visible change for existing users, a one-time global migration (
dm_bar_height_ui_units_v1) multiplies the stored values by the old factor (768 / screen height / ppUIScale), so every profile that exists at update time keeps its exact rendered size. Pixel-perfect setups (factor within 1%) are left untouched. It is global rather than profile-scoped on purpose: profile stamps ride exports, so a profile-scope migration would convert old import strings with the recipient's factor and freeze their UI scale into the value. After the migration has run, imported values are read as UI units and render at the same relative size for everyone. A per-profile stamp keeps the body idempotent if a full-account import replaces the global migration flags.Known limit: profiles that were imported before this update cannot be told apart from the user's own, so they keep their current look; re-importing the string after the update gives the exporter's intended size.
How was it tested?
Tested in-game on live at a non-pixel-perfect UI scale (factor 0.75): the migration ran without errors, converted the stored Bar Height from 30 to 22.5, and the bars rendered exactly as before the update.
Screenshots
N/A: existing profiles render unchanged by design.
Checklist
HookScript/hooksecurefunconly, neverSetScripton Blizzard frames: only addon-owned frames are touched