Is your feature request related to a problem? Please describe.
When running StaxRip on High DPI displays (e.g., 150%, 200% scaling on 4K monitors), the text of "Tick" controls (such as CheckBox and RadioButton) that are located within deeply nested UI containers (e.g., Panel -> GroupBox -> TableLayoutPanel -> CheckBox) gets truncated, squished, or pushed entirely out of the visible bounds.
Currently, users might try to work around this by manually forcing the executable's Compatibility DPI settings to System (Enhanced) via Windows properties. However, this is a flawed workaround that results in blurry UI rendering and conflicts with internal .NET scaling logic.
Root Cause , Winforms bug ?
This is a well-known legacy limitation of the Windows Forms scaling engine:
The Double Scaling Bug: When controls are deeply nested, the legacy AutoScaleMode.Font triggers recursive scaling calculations. The bounding box of the CheckBox fails to scale proportionally with the GDI+ rendered Font size, causing the text to clip.
System DPI vs. Per-Monitor DPI: StaxRip's current DPI handling may not be fully leveraging the modern Windows 10/11 DPI subsystem, leading to layout corruption when moving the app between monitors with different scale factors.
Describe the solution you'd like
Proposed Solution: Implementing Per-Monitor V2
To permanently resolve this without rewriting the UI, StaxRip should explicitly opt-in to Per-Monitor V2 DPI Awareness.
Describe alternatives you've considered
No response
Additional context
No response
Is your feature request related to a problem? Please describe.
When running StaxRip on High DPI displays (e.g., 150%, 200% scaling on 4K monitors), the text of "Tick" controls (such as CheckBox and RadioButton) that are located within deeply nested UI containers (e.g., Panel -> GroupBox -> TableLayoutPanel -> CheckBox) gets truncated, squished, or pushed entirely out of the visible bounds.
Currently, users might try to work around this by manually forcing the executable's Compatibility DPI settings to System (Enhanced) via Windows properties. However, this is a flawed workaround that results in blurry UI rendering and conflicts with internal .NET scaling logic.
Root Cause , Winforms bug ?
This is a well-known legacy limitation of the Windows Forms scaling engine:
The Double Scaling Bug: When controls are deeply nested, the legacy AutoScaleMode.Font triggers recursive scaling calculations. The bounding box of the CheckBox fails to scale proportionally with the GDI+ rendered Font size, causing the text to clip.
System DPI vs. Per-Monitor DPI: StaxRip's current DPI handling may not be fully leveraging the modern Windows 10/11 DPI subsystem, leading to layout corruption when moving the app between monitors with different scale factors.
Describe the solution you'd like
Proposed Solution: Implementing Per-Monitor V2
To permanently resolve this without rewriting the UI, StaxRip should explicitly opt-in to Per-Monitor V2 DPI Awareness.
Describe alternatives you've considered
No response
Additional context
No response