mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-26 15:55:58 +03:00
[GH-ISSUE #474] Cut out UI on high DPI display Win10 #251
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#251
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ViRb3 on GitHub (Jul 1, 2016).
Original GitHub issue: https://github.com/quasar/Quasar/issues/474
This is the case everywhere in Quasar RAT.
125% scaling, disabling DPI scaling via Compatibility tab has no effect.
@caesay commented on GitHub (Jul 3, 2016):
I'm on windows 10 at the latest source with a high DPI display and can't reproduce this issue. Fixed?
@MaxXor commented on GitHub (Jul 3, 2016):
@caesay I didn't change anything yet. Strange. Do you use Quasar from the latest commit?
@ViRb3 Do you use Quasar from the latest commit?
@caesay commented on GitHub (Jul 3, 2016):
@MaxXor Yeah, I just cloned it. I'm on
630f791. I've dealt with a lot of DPI issues in my projects and I thought this issue looked strange. On high DPI usually the application is either tiny because its not scaled at all, or blurry because the application was not DPI aware and windows does a raster scaling on it - I've never seen the window stay small and the content get bigger. It could be a font size thing, I'll try and dig a bit more tomorrow.@MaxXor commented on GitHub (Jul 3, 2016):
@caesay So how does it look on your screen? Can you post a screenshot if possible? Is it tiny or blurry?
@caesay commented on GitHub (Jul 3, 2016):
@MaxXor You've correctly left out the dpi awareness tag from the manifest, so its currently being scaled by windows. It doesn't look bad, though. Unless you're looking at it on a 4K screen you probably won't be overly bothered by the windows scaling / blurriness.
Personally I don't think that this is the type of application that needs crisp visuals, and in the case that it is I would definitely recommend WPF. That being said, if you're curious you can look into the Form properties
AutoScaleDimensionsandAutoScaleMode. When a WinForms application is set as DPI-Aware I believe .Net takes over and those are the values that are used to calculate the scaling.Unfortunately, neither WPF nor WinForms properly support varied monitor-independent DPI settings, so if you set your application to DPI-Aware without handling this yourself, your scaling will be off when moving your window across monitor boundaries with different DPI's. Right now, windows visualizes this for you and i'd recommend you leave it that way.
The problem that i think is causing this is what i call "XP Scaling", which appropriately dates back to XP, It basically scales only system fonts and some system UI elements like titlebars, scrollbars, etc. leaving the rest of the interface intact. So when you move your application to a higher DPI environment, the only difference is that the text suddenly gets bigger. This sounds like the issue, so its probably a setting on @ViRb3 's computer to utilize this scaling method instead of the window virtualization that you usually see.
@ViRb3 commented on GitHub (Jul 3, 2016):
Yes, indeed, I am using Windows 8 DPI scaling instead of Windows 10 since many of my programs don't support it and get blurred. Any chance to support both scaling methods?
@MaxXor commented on GitHub (Aug 12, 2016):
Thanks for all your input @ViRb3 and @caesay! 👍 I think it's fixed now to be correctly DPI aware, I've tested it in VM with DPI set to 125%.
Can you confirm it's working correctly with the latest commit
github.com/quasar/QuasarRAT@0d3a3e427d?