← All posts ·

Fix Plugin UI Scaling: Windows PMv2, macOS, JUCE for Developers

Fix Plugin UI Scaling: Windows PMv2, macOS, JUCE for Developers

Developer comparing plugin interfaces at different scales

Most plugin scaling problems come from a mismatch between how the host or operating system handles DPI and how the plugin itself responds to it. Users can often get relief by toggling host or Windows display scaling settings or floating the plugin editor. Developers need to respond properly to DPI change callbacks or render inside a scalable container. The rest of this guide walks through both paths in detail.

TL;DR:

  • Plugins that are not DPI-aware or respond poorly to DPI changes can appear tiny, blurry, or misaligned, especially when moved between monitors with different scales.
  • Windows recommends declaring per-monitor DPI awareness and handling WM_DPICHANGED to adjust layouts and assets dynamically, but some hosts may ignore these settings, requiring workarounds like floating the plugin window.
  • macOS manages resolution scaling through backingScaleFactor and usually requires no additional code, except when drawing directly into bitmaps, which then need manual scale adjustments.
  • Using vector-based drawing for UI elements and loading multiple resolution assets improves sharpness across displays, while relying on font rendering from the OS avoids jagged text at various scales.
  • Developers should focus on creating scalable containers and reflow logic driven by real-time scale factors rather than hard-coded pixel positions to ensure consistent UI behavior across host applications and display configurations.

Table of Contents

Core causes and concepts behind plugin UI scaling problems

A screen's physical pixels and an application's logical pixels are not the same thing. Confusion between these two coordinate systems is the root of almost every scaling complaint.

Bitmap scaling happens when the OS does not know an application understands DPI, so it renders the app at its native size, then stretches the resulting bitmap to fill the correct physical area, producing blur. DPI-aware scaling is different: the app itself redraws content at the new resolution, keeping edges sharp.

Hosts complicate this further because a plugin editor is usually a child window parented inside the host's own window. If the host is DPI-aware but the plugin is not (or the reverse), the two can disagree about which coordinate space to use, and the plugin either shrinks to a corner of its allotted space or gets stretched by Windows.

Readers can usually identify the type of problem from its symptoms:

Windows: per-monitor DPI and practical developer steps

Windows has moved through several DPI awareness models, and the current recommended standard is Per-Monitor V2, known as PMv2. Under PMv2, Windows notifies both top-level and child windows whenever DPI changes, whether from moving a window to a different monitor or from a user changing display scaling. Microsoft's own guidance on high DPI desktop development lays out the steps: declare DPI awareness in the application manifest, respond to the WM_DPICHANGED message, reload high-resolution bitmap assets, and use DPI-aware sizing APIs. The Windows 10 Creators Update announcement explains why PMv2 exists: it stops Windows from bitmap-stretching the whole application and instead hands rendering and layout control to the developer, which is sharper but requires more work.

Two related APIs often confuse developers. SetProcessDpiAwarenessContext sets DPI awareness for the entire process at startup and is the simplest option for a standalone application. SetThreadDpiAwarenessContext lets a single thread temporarily switch DPI context, which matters for plugins because a host process may already have its own DPI awareness set and a plugin cannot always change it at the process level. According to Microsoft's notes on DPI improvements for desktop applications, mixing awareness contexts within one process is supported but some Win32 APIs are not DPI-context aware themselves, so calls need the DPI-specific variants or unexpected sizing results can appear.

A practical developer checklist for Windows:

  1. Set the correct DPI awareness flag in the plugin's manifest or request it at runtime with SetThreadDpiAwarenessContext.
  2. Listen for WM_DPICHANGED and treat it as a trigger to recalculate layout, not just repaint.
  3. Reload or re-rasterize bitmap assets at the new DPI rather than stretching cached images.
  4. Query the current DPI with GetDpiForWindow and size UI elements with GetSystemMetricsForDpi instead of hard-coded constants.
  5. Test by dragging the plugin editor between two monitors set to different scale percentages.

Pro Tip: If a host keeps ignoring your DPI awareness request, try opening the editor in a floating top-level window instead of the host-parented child window; it sidesteps a surprising number of host-specific quirks.

For users hitting this on the host side rather than in code they control, three things are worth trying before filing a bug: check whether the host offers its own UI scaling preference, adjust Windows display scaling under Settings, and look for a host-specific compatibility override for older plugins.

macOS: backingScaleFactor, layer-backed views, and when to intervene

Cocoa and AppKit handle most resolution independence automatically through a value called backingScaleFactor. Apple's documentation on NSScreen and backingScaleFactor describes it as typically 1.0 on standard displays and 2.0 on Retina displays, and it updates automatically as a window moves between screens with different densities. For most plugin UIs built with standard AppKit views, this means the framework already handles scaling correctly without extra code.

The exception is when a plugin draws directly into a Core Animation layer using bitmaps. Apple's Core Animation guide on layer objects notes that layer-backed views normally set contentsScale automatically, but a developer assigning a bitmap directly to a layer has to set that scale manually and supply an image at the matching resolution, or the result looks soft on Retina screens.

Practical steps for macOS developers:

Concrete developer patterns: JUCE and cross-framework strategies

JUCE, one of the most common frameworks for building audio plugins, has an active discussion trail on this exact problem. The recurring pattern from a long-running forum thread on editor scaling is to place the UI inside a child container component and scale that container with an AffineTransform, rather than trying to scale the top-level editor window directly. This isolates scaling logic from the host's own window management and tends to behave more consistently across different DAWs.

That approach has known rough edges. A separate thread on UI scaling at 4k resolutions documents that AffineTransform scaling can break components that manage their own positioning, including popup menus and tooltips, because those elements sometimes calculate screen coordinates outside the transformed container. Developers commonly work around this with custom LookAndFeel overrides or by leaving specific elements deliberately unscaled.

JUCE also exposes a setScaleFactor call, which some hosts respect and others quietly ignore, so relying on it alone is risky. For plugins that are not DPI-aware at all, a forum thread on plugin scaling confusion lays out the blunt tradeoff: draw at native size and stay tiny on high-DPI screens, let the OS bitmap-stretch the window and accept blur, or force a top-level window with a ScopedDPIAwarenessDisabler, which fixes rendering but can introduce window placement quirks.

A workable implementation checklist:

Pro Tip: Store the user's chosen scale preference separately from the plugin's saved state or preset data, since some hosts recall presets in ways that can silently reset a scale setting the user picked deliberately.

Quick fixes and reproducible tests for users and host developers

Before assuming a bug needs a code fix, try the cheap options first. Many hosts offer their own scaling preference independent of the plugin, and detaching the plugin editor into a floating window sometimes resolves rendering issues tied to host window parenting.

  1. Check the host's own DAW-level scaling or zoom preference before touching system settings.
  2. On Windows, try changing display scaling under Settings or moving the plugin window to a different monitor to see if the problem follows the display.
  3. As a last resort, use a Windows compatibility override to force a specific DPI behavior for the host application.
  4. When reporting a bug, include the operating system version, DAW name and version, monitor configuration (resolution and scale percentage), plugin format (VST3, AU, or AAX), a screenshot, and the exact steps that reproduce the issue.

That last point matters more than most bug reports acknowledge: a scaling issue that shows up only when moving between two monitors with different DPI settings looks completely different from one that appears on a single 4K display, and developers need to know which one they are chasing.

Vector DSP's recommended implementation checklist

Building a plugin UI that survives every host and display combination starts with the container, not the pixels. A scalable container with reflow logic driven by the current scale factor avoids the trap of hard-coded pixel offsets that break the moment a user changes displays.

A short list worth adopting on any new plugin project:

A reasonable testing matrix covers current and one prior OS version on both Windows and macOS, at least two common DAWs, and displays at 1080p, 1440p, and 4K with typical scale factors like 100%, 150%, and 200%.

Impact of UI scaling on plugin performance and resource usage

Scaling itself is rarely a heavy computational cost, but the way a plugin implements it can be. Re-rasterizing a full set of bitmap assets every time the scale factor changes is fine as an occasional event triggered by a DPI change, but doing it inside a paint loop or on every window resize event will visibly tax the CPU and cause dropped frames in the editor.

Vector-based drawing generally costs more per frame than blitting a cached bitmap, since the renderer has to recompute paths and fills rather than copying pixels. For static UI elements like background panels or fixed labels, caching a rasterized version at the current scale and only recomputing it on a genuine DPI change strikes a reasonable balance between sharpness and CPU load.

Container-based scaling with an AffineTransform, the common JUCE pattern described earlier, adds a small transform cost on each paint but is generally lighter than re-laying-out every child component from scratch. The heavier cost usually comes from asset reloading, so gating that behind an actual WM_DPICHANGED event rather than every resize is the more efficient design.

None of this affects the plugin's audio engine directly since UI and DSP threads are separate in a well-built plugin, but a UI that stutters or drops frames during a scale change can make an otherwise efficient plugin feel sluggish to the person using it, particularly during live performance or fast automation editing.

Handling legacy plugins without native high-DPI support

Older plugins built before per-monitor DPI awareness became standard often have no concept of a scale factor at all. On Windows, these get bitmap-stretched by the operating system, which is why a plugin built years ago can look noticeably blurrier on a modern 4K display than a plugin updated last year, even though both are technically working as their authors intended.

There is no code-level fix a user can apply to someone else's plugin, but a few mitigations help. Running the host application itself in a DPI-unaware compatibility mode can sometimes prevent the mismatch, though it may affect other parts of the host's own interface. Keeping the plugin window at a modest size rather than resizing it aggressively also reduces how visible the bitmap stretching becomes.

For developers maintaining an older codebase, the practical path forward described in JUCE's own forum discussions is incremental: adopt SetThreadDpiAwarenessContext to opt into per-monitor awareness without rewriting the entire rendering pipeline at once, then layer in reflow logic and asset reloading over subsequent releases. Trying to become fully DPI-aware in one release, on top of years of hard-coded pixel assumptions, is where most legacy migration projects stall. A staged approach, starting with the most common host and OS combination in your user base, ships working fixes sooner than an all-at-once rewrite.

Cross-platform consistency challenges in UI scaling

Windows and macOS solve resolution independence in fundamentally different ways, and a plugin that handles one well does not automatically handle the other. Windows requires explicit opt-in to per-monitor awareness and explicit handling of WM_DPICHANGED, while macOS bakes most of that behavior into AppKit through backingScaleFactor, meaning a developer coming from macOS often underestimates how much manual work Windows requires, and vice versa.

Windows and macOS plugin scaling comparison

Host behavior adds a second layer of inconsistency on top of the OS layer. Some hosts respect a plugin's setScaleFactor call, and others ignore it entirely, according to developer reports on the JUCE forum. That means the same plugin binary can scale correctly in one DAW and incorrectly in another, on the identical operating system and display.

The practical response is to treat host inconsistency as a given rather than a bug to eliminate. Building a plugin's own internal scaling logic that does not depend on the host implementing anything correctly, keeping the container-plus-reflow approach described earlier, tends to produce more consistent results across hosts than relying on host cooperation. Testing across the handful of DAWs your actual users run matters more than testing against a theoretical spec, since real host implementations vary from the documentation in ways that only show up in practice.

Best practices for designing vector-based scalable UI elements

Vector-based UI elements resize cleanly to any scale factor because they are redrawn from mathematical paths rather than stretched from a fixed bitmap. Designing knobs, sliders, and panel outlines as vector paths, using a framework's native drawing APIs (Core Graphics on macOS, Direct2D or a cross-platform library like JUCE's own graphics context) instead of pre-rendered images, removes an entire category of blur-related bug reports.

A few practices make vector-first design workable in practice. Reserve bitmap assets for genuinely photographic or texture-heavy elements, like a wood-grain panel background, where vector drawing would be impractical, and ship those at multiple resolutions rather than relying on stretching.

Text deserves particular attention since font rendering is one of the most visible signs of scaling done wrong. Letting the operating system's own text rendering handle font scaling, rather than rasterizing text into a bitmap at a fixed size, keeps labels sharp at every scale factor and avoids the jagged edges that show up when bitmap text gets stretched.

Testing vector elements across scale factors is simpler than testing bitmap assets since there is no separate asset pipeline to check. The main verification step is confirming that stroke widths, spacing, and hit-testing regions all scale together, since a control that looks correctly sized but has a hit-testing region still calculated at the old scale will feel subtly broken to the person using it even if nothing looks wrong.

Best practices for designing vector-based scalable UI elements — overview diagram

Debugging tips for common UI scaling visual artifacts

Blurry text or edges almost always point to bitmap stretching rather than a genuine rendering bug.

Mis-positioned popup menus or tooltips are a signature symptom of container-based AffineTransform scaling, documented in JUCE's own forum thread on 4K scaling issues: the transform correctly scales the main editor but child elements that calculate their own screen coordinates can end up positioned as if no transform were applied at all. Checking whether the affected element manages its own coordinate calculation, rather than inheriting the parent container's transform, usually identifies the culprit quickly.

If scaling only breaks when moving a plugin window between two monitors with different DPI settings, the issue is almost certainly a missing or incomplete WM_DPICHANGED handler rather than a drawing bug, since the plugin is likely caching layout values computed at the original monitor's scale and never recalculating them.

A useful first debugging step for any of these is isolating whether the problem reproduces in a minimal test host versus only in a specific DAW. If it only appears in one host, the fix likely belongs in how that host is being detected or handled, not in the plugin's general scaling logic. Logging the DPI value the plugin believes it is running at, alongside the actual system DPI, at the moment the glitch appears often reveals the mismatch immediately.

Author perspective on tradeoffs and realistic expectations

Perfect scaling parity across every host, OS version, and monitor combination is not a realistic bar, and chasing it delays shipping fixes that would help most users right away. Hosts implement DPI handling inconsistently enough that some corner cases will always need host-specific workarounds rather than a universal fix.

The better priority is a safe, readable default at common scale factors, then patching known host-specific quirks as they get reported, rather than trying to solve every combination before release. Ship the reflow-and-recalculate approach first: it handles the majority of real-world cases and gives you a stable foundation to patch from.

— Kai

How ToneLab approaches UI robustness

The ToneLab plugin is built around principles such as a scalable interface rather than fixed pixel assumptions, low-latency real-time DSP, and support for major plugin formats like VST3, AU, and AAX for broad DAW compatibility.

Vector-dsp

A few things worth checking if you are evaluating plugins with scaling in mind:

Details on demo access and license pricing for ToneLab are on the pricing page.

Official documentation and key threads to consult next

Before implementing any of the fixes above, read Microsoft's high DPI development guide and Apple's backingScaleFactor documentation directly, alongside the JUCE forum threads referenced throughout this guide, since host behavior changes faster than any secondhand summary.

Sources

FAQ

What does UI scaling do?

UI scaling adjusts how an interface's elements are sized and rendered to match a display's DPI setting, so text, buttons, and controls stay a consistent physical size across screens with different pixel densities. Done correctly, it keeps edges sharp; done poorly, it causes blur or incorrect element sizing.

How to make UI bigger in WoW?

This is a game-specific interface setting handled inside the game's own display or UI options menu, not a plugin or audio software scaling issue. Check the game's video or interface settings for a UI scale slider.

What are the top 5 audio plugins?

There is no single authoritative ranking of top audio plugins, since the best choice depends on the specific task, whether that's EQ, compression, or sound design, and on the DAW and workflow involved. Producers typically choose plugins based on the processing they need rather than a fixed top-five list.

How do I scale the UI in Windows?

Open Windows Settings, go to Display, and adjust the scale percentage under "Scale and layout," which applies system-wide including to DPI-aware applications and plugins. For an individual application that looks blurry after this change, check whether it offers a compatibility override for DPI behavior in its properties menu.

Why do some plugins look tiny on high-resolution monitors?

This usually means the plugin has no DPI awareness at all and is being drawn at its original, smaller intended size without any OS-level stretching applied. Trying a host-level scaling preference or updating to a newer plugin version that supports per-monitor DPI awareness typically resolves it.