I'm running Windows 10 1803 on a laptop, attached to a desktop display. Laptop's display resolution is same as the attached display, 1920x1080 pixel (namely "Full HD").
However the screen sizes differ, the laptop has a 13" display and the desktop display is 27"...
By the settings option: start->system->display I can adjust scaling for each (!) display to the lowest scaling factor "100%" and a highest resolution of FullHD (1080p).
This setting is fine for the laptop display.
However, with the same setting for the 27" everything appears double sized ...
Q1: How does Windows 10 guess the (physical) dimensions of a screen display to get dpi be calculated "per inch"?
Q2: Is there any option to let Windows 10 to render a "virtual" screen resolution higher than the physical maximum on the 27" display?
Q3: Why does Windows 10 ignore the registry dword HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels, when I set the value from initial 96ppi to a higher resolution?
Remark: Since I do not work on a stationary desktop, buying a 4k display is definitely no option and no answer to this topic.
However, using 2k+ displays would solve the problem since Windows will then calculate a reasonable dpi resolution for the attached displays.
Related
system: Ubuntu 20.04.3 LTS
The default Resolution is 1280x720, the DPI is 96.
When adjust the 'fractional scaling' is 125%, I have two options to get the DPI:
Use the command: xrdb -query |grep dpi
the DPI is 192 ??!
Xft.dpi: 192
Use the command: xdpyinfo, the DPI is 120.
screen #0:
dimensions: 2048x1152 pixels (433x244 millimeters)
resolution: 120x120 dots per inch
Why the two commands return different DPI ?
When scaling to 125%, Why the dimensions is 2048x1152 ? (2048/1280 = 1.6, 1152/720 = 1.6)
Is the X11 API is wrong or other problem?
Thanks.
Strictly speaking neither xrdb nor xdpyinfo are the right place to query the screen's pixel density.
xrdb shows you a DPI value, since it's the place where one can (but is not required to!) set a overriding DPI value for Xft, and some desktop environments to, just "because". xdpyinfo shows mostly values that already did exist waaay back in the original X11 core protocol, where one could also specify physical dimensions of a screen. The problem is, that on modern systems, which are capable of dynamically attaching and removing displays, things are done through XRandR and the capability to drive multiple X11 screens on the same X11 display no longer is used (it's all just one large X11 screen now). So depending on how you configured your monitors, the values reported by xdpyinfo are off.
To arrive at the correct pixel density, one must use XRandR (CLI query/set tool name is xrandr) to retrieve information about the physically connected displays. However be advised that it is perfectly possible for several displays of different pixel density to show overlapping regions of the X11 screen, and within those regions there's no unambiguous DPI value available.
I'd like to play some older games on Windows 7. Running them isn't an issue, but the increase of monitor size and pixel density of later monitors is. Pre-rendered games intended to be played full-screen on e.g. a 640x480 resolution are now "blown up" to fit on a complete screen, making everything look unsharp. I've been looking at different solutions, but so far to no avail for a selection of games:
Running the game in "windowed mode" is an option for those games that support it.
DxWnd could be used to force some games in "windowed mode", but it causes some applications to crash as well.
VirtualBox works nicely since it will automatically resize to the applications desired full-screen resolution, but this is no option if VirtualBox's 3D support is insufficient to play the game.
Drivers like those of AMD or NVIDIA provide means to force maintaining pixel aspect ratio if pixel aspect ratio is an issue on wide-screen monitors
All of the above don't work for me for one game, since it does not provide "windowed mode", DxWnd makes it crash, VirtualBox's 3D support is insufficient and aspect ratio isn't an issue on my monitor.
Which brings me to the question: is there a way to lower the screen resolution while maintaining original pixel density of the monitor instead of having it fill up the whole screen? Thus essentially creating a smaller view port for the Windows environment to use and filling up the rest of the screen with big black borders?
Right click on the game and click property's and then try ticking this option.
.
i am building windows store app. I am using windows 8 and WPF with visual studio .net 2012.
UI of this application should be scalable to different screens. I have created a page where the controls (buttons, images, texts) fits correctly when running the app on simulator with resolution 1920 x 1080 for 10.6" screens. The problem is that when i change resolution, controls do not behave correctly
when resolution or screen sizes are increased (ex. 1920 x 1080 for 23" screens) empty spaces are created on the page;
when resolution or screen sizes are decreased (ex. 1024 x 768 for 10.6" screens) controls sizes are increased too and some of them are not visible in UI because they are displayed too far in bottom.
Is there a way to build "scalable" store app which are independent of screen sizes or resolution? Control sizes and font sizes should increase and decrease when resolution change or from one screen to another but all of them should fit in the space and shouldn't create empty areas.
Any help would be very appreciated.
thank you
This MSDN article discusses the guidelines for scaling to screens.
it touches on Screen size, Screen resolution, and Aspect ratio. It provides a table which shows best practices recommended for apps that use scale-to-fit functionality and it touches on adaptive layout. there is a reference to [Guidelines for layouts] at the end of the article as well.
Hope this helps!
http://msdn.microsoft.com/en-us/library/windows/apps/hh780612.aspx
joelcitizen
WindowFromPhysicalPoint is new with Vista. Its documentation is almost identical to WindowFromPoint. What's the difference? Both seem to take an absolute point (offset from screen origin) and return the topmost (Z order) HWND that contains the point.
http://msdn.microsoft.com/en-us/library/ms633533(VS.85).aspx
Windows Vista introduces the concept of physical coordinates. Desktop Window Manager (DWM) scales non-dots per inch (dpi) aware windows when the display is high dpi. The window seen on the screen corresponds to the physical coordinates. The application continues to work in logical space. Therefore, the application's view of the window is different from that which appears on the screen. For scaled windows, logical and physical coordinates are different.
WindowFromPhysicalPoint operates in physical screen coordinates, while WindowFromPoint works with logical ones. To understand the different read this page.
TL;DR; version would be:
Suppose you design a dialog box with a button at coordinates (100,
48). When this dialog box is displayed at the default 96 dpi, the
button is located at physical coordinates of (100, 48). At 120 dpi, it
is located at physical coordinates of (125, 60). But the logical
coordinates are the same at any dpi setting: (100, 48).
So unless you design your app to be DPI aware I would stick with logical coordinates, since most APIs and window messages operate in logical space. Another reason to use logical coordinates is to make your app backward compatible with Windows XP.
We have a requirement where our application needs to support high resolution monitors. Currently, when the application comes up in High res monitor, the text that it displays is too small. We use Arial 12 point font by default.
Now to make the text visible, I need to change the font size proportionally. I am finding it tough to come up with a formula which would give me the target font size given the monitor resolution.
Here is my understanding of the problem.
1) On windows, by default 96 pixels correpond to 1 Logical inch. This means that when the monitor resolution increases, the screen size in logical inches also increase.
2) 1 Point font is 1/72 of a Logical Inch. So combined with the fact that there are 96 Pixels per Logical inch, it turns out that, there are 96/72 Pixels per Point of Font.
This means that for a 12 point font, The number of Pixels it will occupy is 12*96/72 = 16 Pixels.
Now I need to know the scaling factor by which I need to increase these Number of Pixels so that the resultant Font is properly visible. If I know the scaled pixel count, I can get the Font size simply by dividing it by (96/72)
What is the suggested scaling factor which would ensure properly scaled Fonts on all monitor resolutions?
Also, please correct if my understanding is wrong.
There's an example on the MSDN page for LOGFONT structure. Your understanding is correct, you need to scale the point size by vertres / 72.
lfHeight = -PointSize * GetDeviceCaps(hDC, LOGPIXELSY) / 72;
If you set the resolution in Windows to match that of the physical monitor, no adjustment should be needed. Any well written program will do the multiplication and division necessary to scale the font properly, and in the newest versions of Windows the OS will lie about the resolution and scale the fonts automatically.
If you wish to handle this outside of the Windows settings, simply multiply your font size by your actual DPI and divide by 96.
Edit: Beginning with Windows Vista, Windows will not report your actual configured DPI unless you write a DPI-aware program. Microsoft has some guidance on the subject. You might find that the default scaling that Microsoft provides for non-DPI-aware programs is good enough for your purposes.