What is the average and/or maximum height of a viewport (visible area) on a 1024x768 resolution screen? I'd like to know what is considered 'below the fold' for this resolution.
Google had posted some stats at their now defunct browser size tool.
In short, with a 500px height you get 90% of users, 550px gives you 80% and then it drops off quite quickly from there, to just 40% of users at 650px.
At that resolution I'd assume a maximized browser window.
I'd also expect that this will be browser dependent and will further vary with browsers which allow customisation of toolbars etc.
There is no answer to this question!
Profile the browsers (and versions) that are accessing the site and then make assumptions based on the default configurations of those browsers.
Related
After switching to Windows 10, I've noticed that when selecting a lower than normal screen resolution, the panel fit mode will default to "Maintain Aspect Ratio" meaning black bars appear. Every single time I do this, I have to manually set the panel fit mode to "Scale Full Screen".
I do this very frequently so I'd like to automate the process. I can adjust the resolution fine but cannot fine any API whatsoever to adjust the panel fit. Using a registry monitor, I've found that the setting changes some DWM keys. I'm assuming that some function will need to be called programmatically afterwards to apply the changes.
I've found nothing in the DWM API on MSDN, but I could've missed something.
What am I looking for?
I am making my app dpi-aware per monitor by setting <dpiAware>True/PM</dpiAware> in the manifest file. I can verify with process explorer that this is indeed working or by calling GetProcessDpiAwareness.
This is all working fine and I can scale anything in the client area fine in my code. However, my only problem is that if I drag my app from a system-dpi monitor to a non-system dpi monitor, the title bar and any system menu would either become too big or too small. This isn't the case for most built-in apps (e.g. calc, edge browser, etc..) so there must be away to scale it properly. Does anyone how the devs at MS did this?
The screenshot below should explain my problem better. Also notice, that the padding between the close, min, and max button is different when it's scaled (96dpi).
Sample app I'm attaching a very simple app that is per-monitor dpi aware.
The Windows 10 Anniversary Update (v1607) has added a new API you must call to enable DPI scaling of the non-client areas: EnableNonClientDpiScaling. This function should be called, when WM_NCCREATE is received. The message is sent to the window's procedure callback during window creation.
Example:
case WM_NCCREATE:
{
if (!EnableNonClientDpiScaling(hWnd))
{
// Error handling
return FALSE;
}
return DefWindowProcW(...);
}
If the application's DPI-awareness context is DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2, then calling EnableNonClientDpiScaling should be omitted, as it won't have any effect, although the function will still return successfully.
From the documentation:
Non-client scaling for top-level windows is not enabled by default. You must call this API to enable it for each individual top-level window for which you wish to have the non-client area scale automatically. Once you do, there is no way to disable it. Enabling non-client scaling means that all the areas drawn by the system for the window will automatically scale in response to DPI changes on the window. That includes areas like the caption bar, the scrollbars, and the menu bar. You want to call EnableNonClientDpiScaling when you want the operating system to be responsible for rendering these areas automatically at the correct size based on the API of the monitor.
See this blog post for additional information about DPI scaling changes in Windows 10 AU.
Does anyone how the devs at MS did this?
This has a pretty disappointing answer. Using Alin Constantin's WinCheat and inspecting the top-level window of Calculator, I see a window size of 320x576, and a client size that is also 320x576.
In other words, Microsoft entirely avoids the problem by suppressing the non-client area of the window, putting everything in the client area instead. Making this work well for you may involve custom drawing of the title bar.
Something worth noting is that Calculator and e.g. Windows Explorer don't use the same colour for the title bars. Calculator doing custom drawing of the title bar would explain that perfectly.
UPDATE:
It is enough to add new <dpiAwarness> declaration to manifest to solve all this mess. Example is here.
Remnants of former investigations (obsolete):
More investigations on the subject.
System setup: two monitors, one is 96 dpi another one is 267 dpi (Microsoft Surface 4).
Testing window is moved to secondary 96 dpi monitor:
Here is rendering (wrong, IMO) with <dpiAware>true/pm</dpiAware> in manifest:
Note huge size of caption bar and wrong sizes of window icons.
And here is correct rendering using <dpiAware>true</dpiAware>
And I suspect that MSDN documentation is plainly misleading about values of PROCESS_DPI_AWARENESS. I do not see any differences in messages and styles between <dpiAware>true</dpiAware> and <dpiAware>true/pm</dpiAware>. The later one just makes caption larger. In both case application receives WM_DPICHANGED message while moving between monitors with different DPI.
Sigh.
The documentation says:
Note that the non-client area of a per monitor–DPI aware application is not scaled by Windows, and will appear proportionately smaller on a high DPI display.
The Microsoft apps that you link to deal with this by removing the non-client area and making the client area cover the entire window.
I should design a dialog with size 640*480 ,which can be used on 800*600 resolution.
At present my dialog size is 411*292 ,look wise this itself looks good enough ,but actually I was
asked to design dialog with the size I mentioned above.I tried that also but that dialog is too biger
than my earlier dialog of 411*292 size.
while using in 800*600 resolution or my dialog seems to be bigger and not able to see some of my controls
This is size of my dialog,
IDD_DIALOG_MYPAGE DIALOGEX 0, 0, 411, 292
can anyone please let me know how to design a dialog with 640*480 (which should not be bigger).
And how can I make my application to fit to any resolution so that all the controls on the dialog should be visible.
Dialogs are scaled in Dialog Units and Dialog Units scale upon the current UI settings and depend upon the System font. So if the user selects a larger UI representation your Dialog will grow too.
Best advise 1 I could give: Size all you controls by youself. Pick a font you like. Set it to the Control, calculate the positions ofthe new controls and use SetWindowPos/MoveWindow.
Only in this case you have full Control.
You may also use a fixed font size in the Dialog resource, but alos this font scales upon the DPI untis selected for the Screen...
So best advise 2 I could give: Scale upon the DPI/UI Settings and Show the dialog n a size that the user wants too, thats what a normal dialog will do...
You're in for a world of pain. If I understand correctly, you're being asked to make a dialog that will always be 640*480 pixels. It seems like whoever is asking hasn't kept up with UI development since 1995. 'Pixels' are meaningless in 2014. First, the units in resource files are in 'DLUs', 'Dialog Length Units'. See e.g. http://blogs.msdn.com/b/oldnewthing/archive/2004/02/17/74811.aspx and support.microsoft.com/kb/125681 for some starters on how to convert one to the other. However, with high DPI displays these methods are insufficient. Now it doesn't just depend on the size of the system font any more, but also on the settings the user has selected for how big to display 'things' on various monitors, whether to differentiate between monitors at all, etc. See for a start http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266%28v=vs.85%29.aspx . But beware, because there are updates to these API's - e.g. Win7, Win8 and Win8.1 all have new features in this regards.
All of this of course doesn't help you. It's not terribly hard to make a dialog that will fit on 640x480 and up; just make it as small as possible. But this part: "And how can I make my application to fit to any resolution so that all the controls on the dialog should be visible." is really difficult. Does 'any' mean 'also smaller than 640x480'? And does 'fit' mean that it should look 'native' also on higher resolutions? Should the dialog be resizable? You can either go with the simple and robust approach suggested by xMRi above, or you will have to ask whoever is writing your spec to be more clear about what they want, keeping in mind all the things I outlined above.
I have a CListCtrl control (or a ListView in Win32) that is created with LVS_REPORT style.
I am intending to display icons in its items as such:
But the question is what size of icons do I need to make and load?
Let me explain. From the old Win32 samples, I can see that everyone creates image lists with 15x15 pixel icons. But the issue with those is that it looks horribly pixelated on any modern PC with higher DPI settings. Thus I was looking for a dynamic way to determine the appropriate size of image lists for the CListCtrl.
And also the first part of the question, what icon size should I make originally?
EDIT
PS: Since DPI scaling came up, how do you find it out? I'm currently using the following approach:
//No error handling for brevity
HDC hDC = ::GetDC(hAppsMainWindowHandle);
int nCx = ::GetDeviceCaps(hDC, LOGPIXELSX);
int nCy = ::GetDeviceCaps(hDC, LOGPIXELSY);
::ReleaseDC(hAppsMainWindowHandle, hDC);
//I technically get horizontal & vertical scaling --
//can those be different?
double scalingCx = (double)nCx / 96.0; //1.0 = 100%
double scalingCy = (double)nCy / 96.0;
Is font scaling something different?
A list view uses a "small" or "large" image list depending on its mode. In report mode, it uses the "small" image list. You can use GetSystemMetrics() to get the dimensions of "small" images using the SM_CXSMICON and SM_CYSMICON metrics (use SM_CXICON and SM_CYICON for "large" images).
Note that the returned values will be virtual/scaled if your app is not DPI-aware, so to get accurate values, make sure it is DPI-aware via SetProcessDPIAware(), SetProcessDpiAwareness(), or a DPI manifest.
Update: I just ran across this function, might be useful for you when writing a DPI-aware app:
LoadIconWithScaleDown()
Make larger images and let the API scale them down to smaller sizes.
The report style list view wants small icons, that is icons with SM_CXSMICON by SM_CYSMICON metrics. Assuming your app is high DPI aware, then the actual value of these metrics depends on the user's chosen font scaling or DPI setting. So up front you cannot know what size icons should be used. You have to query the system metrics at runtime, and use appropriately sized icons.
Now, what size icons you include in your executable depend on what DPI settings you wish to support. Back in XP days you could reasonably expect to encounter 100% and 125% font scaling. These days, high density display panels are common and you really need to support larger ratios. At least 150% and 200%, and quite probably 175%.
The closest I can find to guidelines is in this MSDN article: http://msdn.microsoft.com/en-US/library/windows/desktop/dn742485.aspx
This article was written around the Vista time frame and already shows its age. I think you have to use these articles as a guide and adapt to the hardware of the day.
You will also find that people run their machines at font scaling values in between the round numbers listed above, and in the article I link to. One of my colleagues runs at 120%. Interestingly this has highlighted various bugs in our code so it's always useful to have someone dog-fooding your program.
When you build your image lists at runtime, size them according to system metrics. And try to avoid scaling icons. For instance, if system metrics suggest an 18px icons, and you only have 16px and 20px icons, then make a new 18px icons. Fill the image with transparent pixels, and blit the 16px icon into the middle of this 18px image. Make the icon out of that. This approach will avoid aliasing problems.
How to scale font sizes based on current DPI settings in VC++/MFC applications ?
As of now when I change the DPI from 100% yo 150% the font sizes remain the same, although the icons will scale down based on the current dpi ..
Please suggest the best way for above problem.
In Windows Vista and 7, the OS tries to hide the DPI from your program and does adjustments behind the scenes. If you want your program to react properly to DPI changes you must follow the guidelines from Microsoft titled Creating a DPI-Aware Application.
By specifying the text and control sizes in DLU's. That happens by default though, so I assume you are generating dialogs dynamically or from a memory-based DLGTEMPLATE. If you, you're (pardon my French) screwed, because you'll have to muck about with converting DLU's to pixels, a very painful and tedious process. Read the following KB articles:
http://support.microsoft.com/default.aspx?scid=kb;en-us;125681
http://support.microsoft.com/default.aspx?scid=kb;en-us;145994
Don't use DPI for font scaling. Instead, use the settings the user has configured in the "Appearance" section of Control Panel.
You might also want to consider making the font size configurable for just your application.