starred/Quasar

Fork 0

mirror of https://github.com/quasar/Quasar.git synced 2026-04-25 23:35:58 +03:00

[GH-ISSUE #423] RDP showing small fraction (upper left) of screen. #214

New issue

Closed

opened 2026-02-27 15:49:22 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 15:49:22 +03:00

Owner

Originally created by @deebug on GitHub (Feb 25, 2016).
Original GitHub issue: https://github.com/quasar/Quasar/issues/423

Originally assigned to: @MaxXor on GitHub.

A desktop with an UHD resolution can't be viewed in its entirety which renders remote administration useless. It shows the top left part of the screen.

This could be either a scaling issue (not showing the entire desktop) or a screen-grabbing issue (not streaming the entire desktop)

OS: Windows 10 Pro 64 bit
Version: 1.2.0.0

Originally created by @deebug on GitHub (Feb 25, 2016). Original GitHub issue: https://github.com/quasar/Quasar/issues/423 Originally assigned to: @MaxXor on GitHub. A desktop with an UHD resolution can't be viewed in its entirety which renders remote administration useless. It shows the top left part of the screen. This could be either a scaling issue (not showing the entire desktop) or a screen-grabbing issue (not streaming the entire desktop) OS: Windows 10 Pro 64 bit Version: 1.2.0.0

kerem

2026-02-27 15:49:22 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 15:49:22 +03:00

Author

Owner

@MaxXor commented on GitHub (Feb 25, 2016):

Sadly I don't have a monitor which supports UHD resolution to figure out the issue. :(

@MaxXor commented on GitHub (Feb 25, 2016): Sadly I don't have a monitor which supports UHD resolution to figure out the issue. :(

kerem commented

2026-02-27 15:49:22 +03:00

Author

Owner

@yankejustin commented on GitHub (Feb 25, 2016):

Neither do I. Hmmm...

@yankejustin commented on GitHub (Feb 25, 2016): Neither do I. Hmmm...

kerem commented

2026-02-27 15:49:22 +03:00

Author

Owner

@deebug commented on GitHub (Feb 27, 2016):

Mouse input is scaled correctly. So the true dimensions are known but somehow the bitmap doesn't reflect that. I'll use a debug build and try to figure this one out myself. I'll keep you posted, eta hopefully during next week.

@deebug commented on GitHub (Feb 27, 2016): Mouse input is scaled correctly. So the true dimensions are known but somehow the bitmap doesn't reflect that. I'll use a debug build and try to figure this one out myself. I'll keep you posted, eta hopefully during next week.

kerem commented

2026-02-27 15:49:23 +03:00

Author

Owner

@deebug commented on GitHub (Feb 29, 2016):

Windows 10 handles DPI scaling a bit differently.

I've learned that with e.g. a global 125% DPI setting the Screen.AllScreens[monitor].Bounds returns a bogus resolution. So this is not the the fault of the ultra-hight resolution (I did assume that at first).

In my test setting, using a Windows 10 machine with a global 125% DPI scaling, the bounds return 1280x720 while the actual resolution was 1600x900.

Creating a graphics instance from the current form and get dpiXand dpiY? No luck, always 96 DPI.

Option 1, not favorable: One could get the real DPI in a rather difficult way

[DllImport("gdi32.dll")]
static extern int GetDeviceCaps(IntPtr hdc, int nIndex);
public enum DeviceCap
{
    VERTRES = 10,
    DESKTOPVERTRES = 117,

    // http://pinvoke.net/default.aspx/gdi32/GetDeviceCaps.html
}  


private float getScalingFactor()
{
    Graphics g = Graphics.FromHwnd(IntPtr.Zero);
    IntPtr desktop = g.GetHdc();
    int LogicalScreenHeight = GetDeviceCaps(desktop, (int)DeviceCap.VERTRES);
    int PhysicalScreenHeight = GetDeviceCaps(desktop, (int)DeviceCap.DESKTOPVERTRES); 

    float ScreenScalingFactor = (float)PhysicalScreenHeight / (float)LogicalScreenHeight;

    return ScreenScalingFactor; // 1.25 = 125%
}

Source

Using the scaling-factor, one can easily calculate the actual width and height.

Option 2, my favorite: Make the client application DPI aware
This fixes the screen bounds without changing code. How? By adding this to your app.manifest:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>

Since the Client isn't really and end-user GUI experience (except for a dialog window) this results in little or no strange GUI scaling issues when the client uses DPI scaling.

To keep this excellent piece of software future proof (high DPI Windows tablets, UHD screens) you probably should look into this issue.

You can find more information about DPI and all it's perils here. A big thanks to Christoph Nahr for his thorough and very comprehensive documentation concerning this issue.

Now then. I'm no expert and I know little about Mono build compatibility but option 2 sounds like a viable solution.

@deebug commented on GitHub (Feb 29, 2016): Windows 10 handles DPI scaling a bit differently. I've learned that with e.g. a global 125% DPI setting the `Screen.AllScreens[monitor].Bounds` returns a bogus resolution. So this is not the the fault of the ultra-hight resolution (I did assume that at first). In my test setting, using a Windows 10 machine with a global 125% DPI scaling, the bounds return 1280x720 while the actual resolution was 1600x900. Creating a graphics instance from the current form and get `dpiX`and `dpiY`? No luck, always 96 DPI. **Option 1, not favorable: One could get the real DPI in a rather difficult way** ``` [DllImport("gdi32.dll")] static extern int GetDeviceCaps(IntPtr hdc, int nIndex); public enum DeviceCap { VERTRES = 10, DESKTOPVERTRES = 117, // http://pinvoke.net/default.aspx/gdi32/GetDeviceCaps.html } private float getScalingFactor() { Graphics g = Graphics.FromHwnd(IntPtr.Zero); IntPtr desktop = g.GetHdc(); int LogicalScreenHeight = GetDeviceCaps(desktop, (int)DeviceCap.VERTRES); int PhysicalScreenHeight = GetDeviceCaps(desktop, (int)DeviceCap.DESKTOPVERTRES); float ScreenScalingFactor = (float)PhysicalScreenHeight / (float)LogicalScreenHeight; return ScreenScalingFactor; // 1.25 = 125% } ``` [Source](http://stackoverflow.com/a/21450169) Using the scaling-factor, one can easily calculate the actual width and height. **Option 2, my favorite: Make the client application DPI aware** This fixes the screen bounds without changing code. How? By adding this to your `app.manifest`: ``` <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware> </windowsSettings> </application> ``` Since the Client isn't really and end-user GUI experience (except for a dialog window) this results in little or no strange GUI scaling issues when the client uses DPI scaling. To keep this excellent piece of software future proof (high DPI Windows tablets, UHD screens) you probably should look into this issue. You can find more information about DPI and all it's perils [here](http://kynosarges.org/WindowsDpi.html). A big thanks to Christoph Nahr for his thorough and very comprehensive documentation concerning this issue. Now then. I'm no expert and I know little about Mono build compatibility but option 2 sounds like a viable solution.

kerem commented

2026-02-27 15:49:23 +03:00

Author

Owner

@MaxXor commented on GitHub (Feb 29, 2016):

Yes, Option 2 sounds very good. I'll add this.

@MaxXor commented on GitHub (Feb 29, 2016): Yes, Option 2 sounds very good. I'll add this.

kerem referenced this issue

2026-02-27 15:52:55 +03:00

[PR #214] [CLOSED] small behavior fix #213 update #1050