solarwinds / OrionSDK

SDK for the SolarWinds Orion platform, including tools, documentation, and samples in PowerShell, C#, Go, Perl, and Java.
https://thwack.com/OrionSDK
Apache License 2.0
397 stars 139 forks source link

Support for HiDPI #269

Closed pstranak-sw closed 3 years ago

pstranak-sw commented 3 years ago

SWQL Studio in version 3.0 declares support for high-DPI displays. However, it doesn't really work:

Comparison: 4K display with 150% DPI

The screenshot comes from a 4K display with 150% DPI scaling.

As you can see in the middle, the rendering of the current version is inconsistent and the app is barely usable.

The example on the right is the same build of SWQL Studio, just with reverted #266 (disabled in config). While blurry, the rendering is consistent and everything works as it should.

The example on the left is the result of this PR. The rendering is correct and sharp. However, spacing between elements is visibly bigger and a few icons are smaller than they should be.

With additional work, that could be improved. But I wanted to implement just the bare minimum to support high-resolution displays. .NET Framework 4.8 doesn't have a great support for this feature and implementing multiple layouts/icon sets for different DPI scalings seemed too much. .NET 5 might help with that. But if anyone has time for it, simply playing with margins/paddings/... could improve the layout a bit.

On displays with 100% DPI scaling the app still looks mostly unchanged. Just spacing between elements is slightly bigger: (opening the screenshots in a separate tab will show the difference) Current version - query: Current version - query PR version - query: PR version - query Current version - search: Current version - search PR version - search: PR version - search

pstranak-sw commented 3 years ago

I changed also the FindReplaceDialog, even though it's originally a 3rd party code. It's development is dead the code itself contains several bugs (maybe another PR in the future). But without the change the Search/Replace feature would be too broken. However, I did not fix the IncrementalSearcher nor the GoToDialog - we don't use them anyway.

pstranak-sw commented 3 years ago

I tested it on two computers:

If anyone wants to try it somewhere else and it doesn't work, please report the results.

danjagnow commented 3 years ago

Added @tdanner as a reviewer since he has made high-DPI changes in the past.

pstranak-sw commented 3 years ago

The latest set of changes fixes a couple of minor issues. But more importantly, instead of using the OS font (e.g. Segoe UI) everywhere, it reverts to using the original mixture of different fonts in different dialogs. It improves the rendering of spacing between elements without having to recalculate the whole layout manually to fit the OS font.

On 1080p with 100% DPI scaling, there is (almost: https://github.com/solarwinds/OrionSDK/pull/269#discussion_r577056553) no visible change between this PR and the latest released version. 1080p with 100% DPI scaling

On 2160p with 150% DPI scaling, the differences between sizes of the different fonts start to show up, but the app still looks fine. Except for some of the icons, which are not scaled at all.

2160p with 150% DPI scaling

I'm not going to work on replacing all the used fonts (Microsoft Sanf Serif 8.25; Tahoma 8.25; Segoe UI 9; Consolas 9.75 and 10) with just the OS UI fonts (Segoe UI and Consolas, by default) in this PR. Rearranging all the UI elements to fit the fonts would take more time than it seems worth right now.

tdanner commented 3 years ago

That didn't come out quite as well as I had hoped. This is 3.0.0.307 on my system at 150%:

image

image

pstranak-sw commented 3 years ago

I managed to reproduce the problem. When I compile the solution as Debug, it works just fine. But when I compile it as Release, it's broken, just as on your screenshots. But I don't see why.

pstranak-sw commented 3 years ago

When I edit the broken Release binary and modify the assembly attribute [assembly: Debuggable] from [assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)] to [assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)] it magically fixes things. Setting just the Debug flag is not enough, disabling optimizations is needed as well.

I have no idea what's going on. If you don't know where the problem could be, feel free to revert the PR. Maybe I'll figure it out in the future.

pstranak-sw commented 3 years ago

272 hopefully fixes the problem.