I've stripped the xserver configuration on my HiDPI laptop down to just:
displayManager: lightdm (autologin, no greeter)
windowManager: xmonad
desktopManager: none (xterm disabled)
And everything is working fine apart from DPI scaling in some places. Specifically: the cursor size and default tty font are both tiny. Apps - terminal emulators, Firefox, etc - are scaling fine as a result of my X settings (below).
Cursor size, and the slow movement that results, is the biggest pain.
So my question is: why would I see proper scaling in some places and not others? What is responsible for the cursor size and other "core" display stuff?
Stuff I've done/tried:
✓ services.xserver.dpi = 180; (sets xserver flag)
✓ .Xresources settings
Xft.dpi: 180
Xft.autohint: 0
Xft.lcdfilter: lcddefault
Xft.hintstyle: hintfull
Xft.hinting: 1
Xft.antialias: 1
Xft.rgba: rgb
✓ export GDK_SCALE=2
✓ export GDK_DPI_SCALE=0.5
✓ export XCURSOR_SIZE=32
✓ export QT_AUTO_SCREEN_SCALE_FACTOR=1
Relevant (?) GH issues:
nixpkgs#22652
Using NixOS 18.03
Having struggled with this for a while, here are my conclusions...
Whatever black magic is at play making the mouse pointer do it's thing, it has no concern for DPI. In retrospect this seems kinda obvious. A mouse pointer moving across a screen is "lower-level" than a GUI application, such that DPI per se is irrelevant.
The fix? Bigger pointer icon (64x64 worked for me) and more sensitive movement (libinput Accel Speed in my case).
Related
I am currently working on an engineering project that will include a 7", 800x480 Raspberry Pi LCD screen to display wether or not an experiment is going accordingly to plan (a parameter's value will be shown in green if so, and red if it isn't). By my calculations, this would mean I am getting a 131 PPI image quality in said screen.
It is important to verify wether or not the information is readable from afar, and for such I am trying to emulate a screen with these properties in my laptop's screen. My best attempt so far was to use Chrome's DevTools, but it seems to only re-size the webpage, and doesn't adjust image's PPI. Is there any other, easier ways to accomplish what I am trying to do?
PS: I could simply connect my screen to the RPi and be done with it, yes, but I got curious if there is any way to do that (also the RPi is currently being used for other purposes, so I can't access it that easily rigth now).
Following DevTool's device mode was the closest I got, due to its abilito to set any image size I wanted, but the PPI does not seem to have been altered.
So I have a big 32 inch display with a resolution of 1440p, and I want to set the DPI scaling to 75% instead of 100%. But I can't find any way to do so on multiple monitors.
I currently have:
Display 1 [2560 x 1440] (Main display I want to change)
Display 2 [2560 x 1440] (This one is 27 inches so it's fine as is)
Display 3 [3840 x 2160] (Set to 100%, fine as it is)
This trick (click me) changes DPI scaling via some registry keys (LogPixels & Win8DpiScaling), but when I use that trick it downscales display 3 instead of display 1.
Is there a way to get this to work? I see no reason for Microsoft to limit the scaling in displays.
Note: I have a 2070 super, all the displays are plugged into the GPU via displayport directly, with the latest avalible firmware at the time of writing (september 2021)
The tl;dr:
Technical limitations aside, there are very solid user experience reasons why this probably isn't allowed.
No, Windows will not let you set UI scaling below 100%.
(even if a stable workaround were to be discovered, most users would probably be quite unhappy with the results)
While I would love¹ to be proven incorrect, the implications of scaling at less than 100% are so fraught that this limitation is unlikely to change in the near future.
Background:
This has been the case for ages, likely since Windows first introduced the feature.
Compatibility with current software
The only ~purely technical~ reason I can think of:
The 100% scaling size likely uses the smallest base image (e.g. Explorer and Taskbar icons, mouse and text cursors) resources included in various existing Microsoft and 3rd-party applications.
User experience
Going below the 100% point may cause small UI text and icons, especially in application toolbars and the Taskbar to be blurred to the point of ambiguity.
Those fine lines in the taskbar 'Windows' menu icon? Blurred or gone.
Taken to the extreme, the UI ~might~ become so unreadable that the user is effectively prevented from being able to read the text even in the 'Settings' window and therefore is 'stuck': i.e. not able to navigate through 'Settings' to restore the original '100%' scaling mode.
(Luckily, Windows is never used to run any SCADA software where confusing two icons could theoretically cost money or lives.)
Performance:
Since those carefully-designed graphic assets don't exist, if sub-100% scaling were allowed, it would also likely cause extra CPU/GPU workload - that is why only certain fixed sizes of up-sampling are shown on the normal Display settings screen and why the Advanced scaling settings screen warns that custom scaling between 100-500% is "not recommended".
That might also apply to any fixed scaling option offered below 100%, and absolutely would for custom scaling sizes.
Some people enjoy reading:
Vector-based TrueType/OpenType fonts usually contain a ~lot~ of manual tweaking / hints to enable readable display of very small point sizes.
The marketing department & friends of the C-suite
Could they implement this at a limited range of options? 90%? 75%?
Perhaps - but it's extra testing for a horrible-looking edge case.
The existence of the option, even if only available as a registry hack, might cause some people to actually use it in kiosks and other public-facing displays; this risks the same sort of bad PR as when a BSOD is seen on the 'arrivals' screen at a train station or airport monitor.
Combined with the first example below, even a 90% option could cause trouble in some environments.
Example and tutorial:
Imagine how Windows might look displayed on one of those cheapo '1080p-supported' projectors that actually only contains an imager with a native pixel resolution of, say, 1024x576 (or even 480x234).
Windows thinks it can send 1080p, since that what the HDMI connection advertises, so it does: any text / vector content looks atrocious.
(At least in this case the user could normally² unplug the projector and reconnect to a normal monitor to restore functionality.)
See for yourself... while connected to any monitor (at that monitor's native resolution), with Windows set to 100% scaling:
Open Windows Notepad
Type or paste in any block of text
Now, use the Zoom Out command from the View menu³ five or more times in a row
While not an exact analogue, you may still see how hard it could be to read down-sampled text, even when very high-contrast (the best-case scenario).
¹: As someone currently typing this very answer on a 1080p connection to a 55" 4K television as a second monitor, I came across the question very much hoping this was possible. Sadly, logic intervened and killed my potential joy.
²: Unless the computer is actually stored somewhere locked or inaccessible, such as a NUC-style PC hidden above the false ceiling in a conference room.
³: Alternatively, press <CTRL>-<Minus> five or more times.
My application happens to be written in Python using pygame, which wraps SDL, but I'm imagining that this is probably a more-general question to do with the Windows API.
In some of my Python applications, I want pixel-for-pixel control under Windows 10 even at high resolutions. I want to be able to ensure, for example, that if my Surface Pro 3 has a native resolution of 2160x1440, then I can enter full-screen mode with those dimensions and present a full-screen image of exactly those dimensions.
The barrier to this is "DPI scaling". By default, under Windows' Settings -> Display, the value of "Change the size of text, apps, and other items" is "150% (Recommended)" and the result is that I only see 2/3 of my image. I have discovered how to fix this behaviour...
systemwide, by moving that slider down to 100% (but that's undesirable for most other applications)
just for python.exe and pythonw.exe, by going to those executables' "Properties" dialogs, Compatibility tab, and clicking "Disable display scaling on high DPI settings". I can do this for me alone, or for all users. I can also automate this process by setting the appropriate keys in the registry programmatically. Or via .exe.manifest files (which also seems to require a global setting change, to prefer external manifests, with possible side-effects on other applications).
My question is: can I do this from inside my program on a per-launch basis, before I open my graphics window? I, or anyone using my software, won't necessarily want this setting enabled for all Python applications ever—we might want it just when running particular Python programs. I'm imagining there might be a winapi call (or failing that something inside SDL, wrapped by pygame) that could achieve this, but so far my research is drawing a blank.
Here's the answer I was looking for, based on comments by IInspectable and andlabs (many thanks):
import ctypes
# Query DPI Awareness (Windows 10 and 8)
awareness = ctypes.c_int()
errorCode = ctypes.windll.shcore.GetProcessDpiAwareness(0, ctypes.byref(awareness))
print(awareness.value)
# Set DPI Awareness (Windows 10 and 8)
errorCode = ctypes.windll.shcore.SetProcessDpiAwareness(2)
# the argument is the awareness level, which can be 0, 1 or 2:
# for 1-to-1 pixel control I seem to need it to be non-zero (I'm using level 2)
# Set DPI Awareness (Windows 7 and Vista)
success = ctypes.windll.user32.SetProcessDPIAware()
# behaviour on later OSes is undefined, although when I run it on my Windows 10 machine, it seems to work with effects identical to SetProcessDpiAwareness(1)
The awareness levels are defined as follows:
typedef enum _PROCESS_DPI_AWARENESS {
PROCESS_DPI_UNAWARE = 0,
/* DPI unaware. This app does not scale for DPI changes and is
always assumed to have a scale factor of 100% (96 DPI). It
will be automatically scaled by the system on any other DPI
setting. */
PROCESS_SYSTEM_DPI_AWARE = 1,
/* System DPI aware. This app does not scale for DPI changes.
It will query for the DPI once and use that value for the
lifetime of the app. If the DPI changes, the app will not
adjust to the new DPI value. It will be automatically scaled
up or down by the system when the DPI changes from the system
value. */
PROCESS_PER_MONITOR_DPI_AWARE = 2
/* Per monitor DPI aware. This app checks for the DPI when it is
created and adjusts the scale factor whenever the DPI changes.
These applications are not automatically scaled by the system. */
} PROCESS_DPI_AWARENESS;
Level 2 sounds most appropriate for my goal although 1 will also work provided there's no change in system resolution / DPI scaling.
SetProcessDpiAwareness will fail with errorCode = -2147024891 = 0x80070005 = E_ACCESSDENIED if it has previously been called for the current process (and that includes being called by the system when the process is launched, due to a registry key or .manifest file)
On Windows 8.1 I created a firefox addon to take a screenshot.
I'm having an issue. This is what I'm doing:
I have a setup like this (mon1 is not primary monitor, has res of 1920x1080, monitor 2 is primary and has res of 1280x1024)
Screenshot all monitors to ImageData.
Open two featureless/borderless windows with this code:
Then after window opens I move it to the originX and originY of each monitor then make it fullscreen:
aEditorDOMWindow.moveTo(colMon[iMon].x, colMon[iMon].y);
aEditorDOMWindow.focus();
aEditorDOMWindow.fullScreen = true;
Then I create a canvas with width x height matching screen resolution in each window and draw to it the monitors screenshot
So now the problem is, the windows open on monitor 2, then when i move it to monitor 1 and inspect canvas, the size is 1920x1080 which matches the resolution, but in the video recording below I measured it with photoshop and it visually is actually 2880 x 1620.
Here is a youtube screencast demonstrating it:
Youtube :: Why other monitor almost double size?
I always notice as I drag a window from one monitor to another it slightly changes size, what is this called? Is it specific to Window8.1+? Is there anyway with WinAPI I can trigger this resize?
You no doubt see the DPI virtualization feature of Windows at work. Nothing you can do about it in this case, it is up to the main application to declare itself multi-monitor DPI aware.
It doesn't, the subject of Mozilla bug #890156. Two years old already, they are not in a hurry to fix it. Not a lot of votes, you can add one.
For some time now, I've been working on a series of GUIs. I use a Mac running OSX to write all of my code, and the problem I've encountered is that it there are deviations in appearance when the GUIs are used in windows, some of which are minor, and some of which are very significant.
1) The text in the windows version is substantially larger overall. This results in some of my button titles simply going off the button, or panel titles moving beyond the panel.
2) Axes appear to be different dimensions between Mac and Windows. i.e. An axis that appears square on my Mac will appear elongated or rectangular on windows, and vice versa.
3) Graphical displays are different. This is the real problem. Some of my GUIs use axes to display text and model chemical reaction animations. On the Mac, they look perfectly fine, but on the windows system, the sizing is completely off.
I've set all "Units" to "characters" as suggested by the Mathworks help page, and I do not specify any fonts to allow each system to use its default. I have however, specified font sizes, but apparently, 12 point font on windows appears very different from 12 point font on mac.
Are there any ways around these problems? I thought setting a specified font size and allowing for use of default fonts would fix this, but it hasn't, and I'm a little dry for ideas at this point.
Try working in 'pixels' or absolute size units instead of 'characters', and apply a scaling factor to your font sizes.
Setting 'Units' to 'characters' is probably the wrong way to go for portability, and could be the main cause of your display sizing issues. Which specific Matlab page recommended that you do so? Was it talking about cross-platform portability? The characters unit is very convenient to work with, but it is tied to the font metrics for the default system font. (See the doco for Units property at http://www.mathworks.com/help/matlab/ref/axes_props.html). That's going to differ between different operating systems. Working with 'pixels' or inches/centimeters/points, which are absolute, will probably give you more uniform results across operating systems.
And you're not wrong: OS X tends to display fonts of a given size on screen smaller than Windows does. (Generally; YMMV depending on your display DPI and system settings and other things.) For example, I run my terminals and text editors at 10 or 12 points in Windows, but 14 point or larger on Mac. So apply a scaling factor to the font sizes you set in your GUI. Figure out what looks good on Mac, and then scale it in your code to something like windows_font_size = floor(mac_font_size * 0.8) and see how it goes.
If you want to be more precise in scaling, you could grab the ScreenPixelsPerInch and ScreenSize root properties with get(0,...). You may also be able to call down in to Java code to get precise font metrics info to help with font scaling choices.
Either way, you're going to have to test your code on both systems instead of just expecting it to work portably. If you don't have ready access to a Windows development system, consider setting up a Windows VM on your Mac. With file sharing between the two sides, you'll be able to try your code out on both platforms right as you work with it.
I encountered this problem as well.
Calling this function within the FUNCTIONNAME_OpeningFcn might alleviate your issues:
function decreaseFontSizesIfReq(handles)
% make all fonts smaller on a non-mac-osx computer
persistent fontSizeDecreased
fontSizeDecreased = [];
if ~ismac()
% No MAC OSX detected; decrease font sizes
if isempty(fontSizeDecreased)
for afield = fieldnames(handles)'
afield = afield{1}; %#ok<FXSET>
try %#ok<TRYNC>
set(handles.(afield),'FontSize',get(handles.(afield),'FontSize')*0.75); % decrease font size
end
end
fontSizeDecreased=1; % do not perform this step again.
end
end