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.
Related
Okay... hey guys,
I hope you can help me solve this one, or maybe someone will be able to provide a comprehensible reasoning for the following.
The newer versions of the Opera and Firefox browser are forcing a reduced available width onto websites. I assume that's in order to fit their content better (with less unused space).
However, if a website's content exceeds the width of 1536 px (and your screen resolution is 1920 px in width), the available width is still capped at 1536 (a horizontal scrollbar appears).
I've prepared a demo as well:
http://r00t.li/test/opera_fittowidth_fckup.html
So I think it's a nice feature of those browsers to fit website content to the available width as it often improves the readability, but what on earth can I do if I want/need to utilize the full screen width?
I've toyed around with different meta tag viewport settings, but it hadn't have any effect. I guess that's for mobile devices only.
Ok, so after some more searching I found the culprit: the DPI setting of windows affects how these browsers display websites. For instance with a DPI of 125%, the Opera and Firefox browser try to apply this not just to their UI, but also to websites by rendering the content bigger (even though the website zoom in the browser is set to 100%), effectively decreasing the available pixel width.
As a web designer, one has apparently absolutely no control over this. And even if a user takes the time to change the windows DPI to 100%, it's not an acceptable solution. Granted, the websites look normal again, but the font-size of the windows UI is tiny - very hard to read.
But I don't want this to become a rant, so again; the solution is to change your windows DPI setting to 100%. This can be done like this:
Right click on the desktop and select Screen Resolution
Click on "Make text and other items larger and smaller"
Choose 100% and save your settings
Very sad that those browser developers made that decision... as if the 100 milliseconds it takes the user to hold Ctrl and tick the mouse wheel one or two times were too much.
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
How can I have a vb6 program which opens correctly in 1280*1024 but when switched to other resolutions say 640*480 i can only see half of the screen. how to re-size my vb6 program so that it automatically fits in any screen resolution?
You need to use the Screen object, this will always give you the current resolution in pixels:
Dim screenwidth,screenheight As Single
screenwidth = Screen.Width \ Screen.TwipsPerPixelX
screenheight = Screen.Height \ Screen.TwipsPerPixelY
Usually a Form amenable to resizing has controls that lend themselves to a "flow" layout. Often this is something like a TextBox, grid control, etc. that supports scrollbars. You shrink/grow such controls as required after allocating positions for (i.e. moving) the fixed-size elements like buttons and such.
For a busy Form with lots of fixed size controls that isn't "document oriented" there is no set answer. Sometimes creating a scrollable Form makes sense but usually it doesn't.
Some people try to resize "fixed" elements, change fonts sizes, etc. This can produce results of mixed quality though, sometimes good and sometimes not.
Considerations about the Form size are best made up front as part of the design process. For some applications it might be better to decide on a minimum supported Form size. In other cases you may have to break things up with dialog Forms or tab controls.
There's no easy way to do this in VB6, like there is in .Net. You have to manually resize everything in the form's Resized event handler based on the new form's client size. It's a pain, and a huge mess, but it's the only way to do it.
Correction: There's never only one way to do things, but I've been programming VB6 for several years, and usually just writing it into the Resize handler is straightforward enough, and I haven't found any good way to do it other than that.
Have you tried any 3rd party tools for doing this? Here's (a free) one that seems to work :-
ActiveResize Control Lite - I created a quick project to try it and it does what it says on the tin!
The lite version has some limitions such as number of forms in project, number of controls on form etc. You can also buy a Standard or Professional version if you need more functionality.
I know we've spent countless hours trying to implement our own resizing code only to remove it all and fix the location of most controls, move a few to make it look better and limit the min/max functionality of the form - none of which give a nice user experience. If we needed to do it again I probably use this control (or a similar one) just for the time savings.
I use ComponentOne SizerOne
The C1Elastic control allow from resizing and maintain the aspect ratio, resizing the inside controls on the setting you defined.
It's not free, but it payed itself with all the time I saved.
Form1.Height = Screen.Height
Form1.Width = Screen.Width
This code sets form size according to screen resolution.
"ActiveResize Control Lite" ActiveX tool is limited to 20 controls per form.
Once we know the screen resolution, there are a number of things you can do.
• The easiest solution would be do design different form to accommodate the four most popular monitor resolutions – 640 x 480, 800 x 600, 1024 x 768, and 1600 x 1200.
• Alternatively, we could write code that dynamically resizes and relocates every control on the form, based on the screen resolution – not an easy undertaking!
• Third party controls that resize the controls based on the screen resolution are quite effective. On the whole, though, it's better to just avoid this kind of problem, if you can. For example, see Creating Flexible Forms in Visual Basic (Flexi-Forms) at codeguru.com
To auto fit screen resolution you need to download an active x, drag it on your conform.
Search for "veg gold vb6.0 screen Resize".
I recently had a client contact me asking for an update to his project that I used to maintain/develop years ago.
It was done using Macromedia Director (now Adobe Director) and Lingo. Since I haven't developed anything using these technology in such a long time I need some assistance.
The majority of the changes are simple, but what has got me stumped is making the application be able to toggle between full-screen projector and windowed-mode.
This is how it is organised:
I have a stub projector, which is lightweight and ensures a quick start-time.
The stub projector loads the main movie. ("#::Content:Main")
This stub projector is published with in full-screen mode.
Now, I can create a projector that is windowed and one that is full-screen mode by publishing separate executables. However what the client wants is the ability to switch this at runtime - is this even possible?
I have found a few workarounds that kinda work (setting the display-rect and stage-rect to the desktop size) but introduce numerous compatibility issues.
Any advice? Solutions?
I am tempted to say that it isn't possible to switch at runtime and recommend that he publishes either a full-screen or a windowed version.
For future reference: http://www.directorforum.com/showthread.php?p=38795#post38795
Well there are different ways to
define "full screen", but all can be
done at runtime:
1) The projector automatically adjusts
the computer's display resolution to
match the dimensions of the movie and
hides the taskbar/dock. This is
generally what "full screen" means in
modern parlance. You can check out
various Xtras for switching the
resolution on the fly.
2) In Director terms, publishing a
projector 'full screen' just means
that the projector window has no
titlebar, takes up the full dimensions
of the display, hides the
taskbar/dock, and has the movie
content centered on screen framed by a
solid background color. This is a
pretty lame implementation of full
screen since it doesn't make the movie
appear any bigger onscreen. This can
be set at runtime by manipulating the
rects that you mention and using an
Xtra to hide the taskbar. Not sure
what "compatibility issues" you ran
into.
3) Graphically stretch the movie so
that its actual content takes up the
entire screen. The easiest way to do
this is by altering the drawRect. But
this can result in distorted graphics
depending on how much stretching is
occurring, since no antialiasing is
used to smooth the stretched pixels.
I noticed StackOverflow appears to be targeting screen resolution widths of 1024px or more. I also checked Amazon, NBC, MSN, & AOL which target more lay users, and they all appear to be targeting the same width.
Is 1024px the current recommended width for web apps targeting the largest cross-section of users who use default monitor resolution/browser size?
Use liquid layout. Then you can easily accommodate everyone from ~800 to ~1600 width, and with a bit more work and care even lower-resolution devices too. This also gives users #1024 some leeway to zoom the page if they find the text too small.
Remember there'll be things like netbooks which don't have the big screens we expect today. You can get away with a horizontal scrollbar, but if you have to scroll the page just to get the main body of text in, you're lost.
Before sounding so condescending, you may want to read up on the modern user base. Netbooks. PDAs. Smartphones. Smartbooks (you do know what those are, being very sophisticated, right?). Programmers who have their screen in portrait orientaton. People who stack their windows side by side. Kiosks.
UPDATE As per conversation with John, I edited the question to change the tenor a bit to reflect his original intent. However, the original paragraph that I wrote is still true- I haven't seen the latest statistics but the days of "90% of users have AxB resultion/window size on their browser" are probably forever gone, what with wide screen laptops and mobile devices. Makes life more exciting for UI designers :)
Having said that, to develop a really usable web site, you need to couple flowing layout with, ideally, ability to use portlets and portal framework (think My Yahoo), so people can choose the page layout most comfortable for them.
make a good use of 960.gs and you will set everything that you need to start a good web site :)
(source: balexandre.com)
The 960 Grid System is an effort to streamline web development workflow by providing commonly used dimensions, based on a width of 960 pixels. There are two variants: 12 and 16 columns, which can be used separately or in tandem.
960 GS it's a lovely start, doing web or images, they have a complete template for almost any good design program (Photoshop, Ilustrator, Fireworks, InDesign, etc) as well a CSS generator and a Grid Overlay to help you with the website.
I use it and it's fantastic! check out the demo
Nettuts has a tutorial and video. WooThemes wrote a post entitled “Why we love 960.gs” and use it as a starting point for their WordPress themes. Spanish speakers can also check out tutorials by Jepser Bernardino and Miguel Angel Alvarez.
Unsophisticated? I think that's a bit of a rude way to describe the unwashed masses. I suppose every one and their dog has a 1024px width monitor now thanks to the likes of dell and others...
The maximum I would consider targeting as my "base" is 1280x1024, but I would be much more likely to go 1024x768.
That said, in my current projects I try to do a liquid layout with a min-width of 800 to accomidate netbooks and usually a max-width of around 1000px (970 usually). Of course, I also have the luxury of designing for myself, so I have the privilege of telling IE6 users that they should upgrade, which makes the liquid layouts much easier to design.
Summary:
Design with your browser's inner dimensions set to 1250x668 to satisfy 92.7% of users.
I like being stats-driven. To this end, W3Schools has a nice Browser Display Statistics page, which they update periodically with new statistics on how common each screen resolution is.
As of January 2015, 92.7% of browsers visiting W3Schools pages were attached to displays larger than 1024x768, though 39.3% of all displays were limited to 768 pixels in height (or lower), mostly due to the 33% of them having 1366x768 displays.
Unfortunately, W3Schools measured screen resolution rather than the inner dimensions used for rendering web page content. It'd be real nice to get stats on users' window.innerWidth and window.innerHeight instead.
Because we don't have these, we have to reserve room for window decorations that may be larger than our own, as well as browser widgets that may further take away from the space dedicated to rendering a web site. Additionally, not all users browse the web in a maximized web browser, though I think we can ignore that if we assume lower-resolution displays will have maximized browsers.
Windows 7 seems the biggest offender at eating up screen real estate, with what I'm measuring as 30-40px for the task bar (I had to search for a screen shot, as I don't run Windows). Firefox with titlebar, menubar, bookmarks toolbar, and status bar eats another 159px while the slimmer modern FF only consumes 64px. Let's use the slim version and assume around 100px of vertical space will be lost. Maximized browsers don't appear to consume any extra horizontal space, so you really only need to account for the scroll bar, but I'd reserve a few pixels for window edges just in case, bringing us up to 30px.
A few years ago (when I did more web design than I do today), I'd size my own browser to an inner size of 800x550 and made sure that most pages would not have scroll bars. Nowadays, it looks like that can be expanded to around an inner size of 1250x668.
You can check your inner size by putting this in your location bar:
javascript:alert(window.innerWidth + "x" + window.innerHeight)
Those values are read-only; you used to be able to run something like this to resize your inner dimensions, but (thanks to abusive advertisers) it no longer works:
javascript:window.resizeTo(window.outerWidth-window.innerWidth+1250,window.outerHeight-window.innerHeight+668)
One parting note: Just because you're assuming a certain size doesn't mean you shouldn't ensure that your site still works at smaller resolutions. The page can be ugly, but it must be functional!