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.
Related
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.
Very large images will not render in Google Chrome (although the scrollbars will still behave as if the image is present). The same images will often render just fine in other browsers.
Here are two sample images. If you're using Google Chrome, you won't see the long red bar:
Short Blue
http://i.stack.imgur.com/ApGfg.png
Long Red
http://i.stack.imgur.com/J2eRf.png
As you can see, the browser thinks the longer image is there, but it simply doesn't render. The image format doesn't seem to matter either: I've tried both PNGs and JPEGs. I've also tested this on two different machines running different operating systems (Windows and OSX). This is obviously a bug, but can anyone think of a workaround that would force Chrome to render large images?
Not that anyone cares or is even looking at this post, but I did find an odd workaround. The problem seems to be with the way Chrome handles zooming. If you set the zoom property to 98.6% and lower or 102.6% and higher, the image will render (setting the zoom property to any value between 98.6% and 102.6% will cause the rendering to fail). Note that the zoom property is not officially defined in CSS, so some browsers may ignore it (which is a good thing in this case since this is a browser-specific hack). As long as you don't mind the image being resized slightly, I suppose this may be the best fix.
In short, the following code produces the desired result, as shown here:
<img style="zoom:98.6%" src="http://i.stack.imgur.com/J2eRf.png">
Update:
Actually, this is a good opportunity to kill two birds with one stone. As screens move to higher resolutions (e.g. the Apple Retina display), web developers will want to start serving up images that are twice as large and then scaling them down by 50%, as suggested here. So, instead of using the zoom property as suggested above, you could simply double the size of the image and render it at half the size:
<img style="width:50%;height:50%;" src="http://i.stack.imgur.com/J2eRf.png">
Not only will this solve your rendering problem in Chrome, but it will make the image look nice and crisp on the next generation of high-resolution displays.
I'm developing an app for WP7 (VS2010 Express for Windows Phone RTM and WP Emulator), but now im facing a big problem related to memory usage.
The app itself has like 12 views, and some of them are reused with different data. It's a newsreader, so the views are mostly listboxes (image thumbnail, stackpanels and textblocks).
The first view has a listbox with 30 items. This takes about 20MB of RAM, but as i navigate between views the current and peak RAM usage start to rise. Well the peak usage it's around 55MB which i think is OK, but the app has a gallery section in which after selecting a thumbnail it navigates to another view which displays a downloaded image (JPEG, 1131px × 1647px, ~486KB) but initially fit to the screen. Until here all good, but for scaling purposes i'm using Laurent Bugnion's Multitouch Behavior and the problem is that when i zoom in the image, the memory usage gets near 90MB (like 87MB last time i tested with the maximum scale size at 2.5).
Also after i navigate the views the current ram usage may permantly reach and stay at 35MB, which i beleive is due to the device caching some things.
So, as the title says, how can i avoid such huge ram usage?
Edit----
Also i'd like to ask if the fact that in my app one can navigate from any view to almost every other and that in between there's always a page transition animation (like the one for the phone list application template in the beta tools), may be contributing to the excessive memory usage.
Generally speaking you want to keep images as small as feasible (in dimensions and color depth, not necessarily file size). In order to display an image, the device must decompress it to an actual Bitmap, so in this case you're looking at a 1131x1647pixel image, let's say at 16bpp, means that you have a 3.7MB memory footprint for the image, not the 486k file size.
Depending on your zoom/rotate, there may be a second copy buffer, so you can effectively double that. It doesn't take long at that rate to get to 90MB. I'd certainly try either download smaller image files or try resizing them locally and then using the resized image.
Well maybe i should look into deepzoom (but when i first read about it, i thought it was for using it with the same image at different sizes, like google maps in satellite view), but yesterday i solved it by using a webbrowser inside my view, so if before i had:
<Image x:Name="imgPlaceHolder" delay:LowProfileImageLoader.UriSource="{Binding Path=ActualImageSource}" MaxHeight="800"
MaxWidth="480" >
<interac:Interaction.Behaviors >
<tbeh:MultiTouchBehavior x:Name="ImageMTB" IsScaleEnabled="True"
MinimumScale="0.4"
MaximumScale="2.5"
IsRotateEnabled="False"
IsDebugModeActive="False"
IsTranslateXEnabled="True"
IsTranslateYEnabled="True"
>
</tbeh:MultiTouchBehavior>
</interac:Interaction.Behaviors>
</Image>
I changed that to:
<phone:WebBrowser Source="{Binding Path=ActualImageSource}" x:Name="wbbigimage" />
It uses less memory and takes care of the zoom with no problems.
I'll wait a bit for someone with a better solution before checking this one.
A couple of things to note. First, make sure that you are clearing out any lists or images that you are using on pages durring the onNavigatedFrom method. The way WP7 Deals with images is "interesting". One of the things I have found to help is to null out the background of any panorama controls when the page is not being displayed.
As for your specific issue, have you considered using a MultiScaleImage (Deep Zoom) to cut down on memory?
http://msdn.microsoft.com/en-us/library/system.windows.controls.multiscaleimage(VS.95).aspx
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 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!