Does anyone know what measurement units are used by Silverlight/WFP? For example, if I create a new button and set its height to 150, is that 150 pixels? points? millimeters?
I design all of my applications in Adobe Illustrator before proceeding to code, and although I try and set everything to the dimensions in my Illustrator file, the Silverlight application is usually larger.
Although in theory, 1 unit in WPF is 1/96th of an inch, that's frequently not the case in practice.
It's usually true when printing. But it's rarely true on screen. The reason for this is that Windows almost always knows the true resolution of a printer, but almost never knows the true resolution of a screen.
For example, I have three screens attached to my computer. Windows thinks that they all have a resolution of 96 pixels per inch. Actually they don't. Two of them have a resolution of 101 pixels per inch, and one has a resolution of 94 pixels per inch. (Why? Because Windows has no way of working the true resolutions out for itself, and I haven't told it. The fiction that they all have the same pixel size is close to the truth, and turns out to be a convenient fiction.)
So when I create, say, a Rectangle in WPF with Width and Height both set to 96, the size of the Rectangle actually depends on which screen it appears on. Windows thinks that all 3 screens have a resolution of 96 pixels per inch, and so it'll render the rectangle as being 96 pixels tall and wide no matter which screen it appears on. That'll make it appear 0.95 inches tall on two of the screens, and 1.02 inches tall on the third.
So in practice, that means that units in WPF on my computer here are either 1/100th of an inch, or 1/94th of an inch in practice. (I.e., in practice, the size of 1 unit in WPF is exactly the size of 1 pixel on my particular setup, no matter how big the pixels happen to be.)
I could change that. I could reconfigure Windows - I could tell it the actual resolution of all 3 screens, in which case the nominal and actual WPF unit sizes would coincide. Or I could lie - I could claim that I have 200 pixel per inch screens, in which case everything would be massive...
The basic problem here is that there is no standard way for the computer to discover the true size of the physical pixels on the screen, and very few people bother to set it up by hand. (And in fact you can cause problems by configuring it 'correctly', because a lot of software doesn't behave correctly when you do.) So the majority of Windows computers don't report physical pixel sizes correctly to WPF - they can't because they don't know.
Consequently, there's no reliable answer to the question - 1 unit in WPF could be pretty much anything on screen. (In practice, most of the time, it turns out to be 1 pixel, simply because if you don't tell Windows anything else, it defaults to assuming that your screens have pixels that are 1/96th of an inch tall, which is the same as 1 WPF unit. And for most desktop screens, that's actually quite likely to be a good guess. But this isn't universal. On systems configured with what used to be called 'large fonts' for example, you'll find a different nominal screen resolution, and 1 WPF unit will correspond to slightly more than 1 physical pixel - about 1.2 in fact.)
With printers, it's all much more predictable. Printers are invariably able to report their resolutions correctly. So if you print something that's 96 WPF units high, you can be confident that it will be 1 inch high.
MSDN's documentation states that the FrameworkElement.Height property (for Silverlight) refers to:
The height, in pixels, of the object
However, for WPF it refers to:
a device-independent unit (1/96th inch) measurement
So, to answer your question... pixels for Silverlight, device-independent units for WPF.
The documentation refers to Pixels, however these are Pixels where there are 96 such pixels per inch. A line of Width 96 when display on a 120 DPI display will be 120 actual device pixels. Similarly such a line drawn on a printer output which has 600 DPI will be 600 pixels long.
They are Device Independent Units.
You can find more detailed explanations here.
Related
WPF documentation and tutorials state that WPF is resolution independent which I understood shows a window in the same size in different resolutions (1600x1200 -> native and 1024x768) and/or DPI settings. However, when I tried a sample app. with different resolutions the sizes are different. On the net I found http://www.wpflearningexperience.com/?p=41, which use "native resolution" in order to see the same window size on different computers, however I could not understand the underlying concept.
Why native resolution for LCD is vital and resolution indepence is a term instead of DPI independence? Probably, I do not know/use terminology well, but I need a clarification in order to understand this issue.
I do not want to answer my own questions, but I think I got the point. Sorry for this premature question, but after a while I noticed the problem.
As far as I understand WPF uses System DPI (which you set by changing through Windows Desktop Settings) as a scale factor. For example in the tutorial above one of the computers have a native resolution of 1600x1200 and 96 DPI (94 actually as stated in the tutorial). Everything is fine because System DPI (96) is quite close to the real DPI (94) and WPF can use this information to scale your window.
As you know a Device Independent Unit is 1/96 inch and with the numbers above real pixel size (physical pixel on your screen) is multiplied with ( (1/96) * 96 ) which is equal to 1. So if you have a window with 300 DIU, then you will see ( 300/96 ) inch on your screen.
However, when you change your resolution without changing System DPI, here comes the problem which confused my mind. Say, you set the screen resolution to 1024x768 without changing the System DPI (still it is 96) and run the application again and you see a bigger window. This is the reqult of wrong System DPI and naturally wrong scale factor for WPF. WPF does not know much about your real DPI, it only uses the information you give to it which is System DPI. Let's recalculate our window size with this new settings. First we need scale factor which is ( (1/96) * 96 ) equal to 1. We can say that 1 logical pixel is also 1 physical pixel on screen. However, we changed the resolution and 300 pixel is not the same with the previous resolution. Previously we have 1600 pixel on the diagonal which is also 17 inch in length. However, we have 1024 pixel for 17 inch now. 300 pixel is almost 5 inch on our new resolution (1024x768), but only 3.18 inch in the previous resolution (1600x1200). Therefore, WPF cannot be resolution independent due to the wrong DPI value and draws a larger window with the new resolution.
So, how I fix the problem (in my words, I do not claim that this is an absolute solution)! When I change the resolution, I also changed the DPI value which is true for this new resolution. For example, for my own monitor the diagonal size is 17 inch with a resolution of 1024x768, I use the formula (1024 pixel / 17 inch) and find that my new true DPI is almost 60 DPI. I set the System DPI to 60 (through the Desktop Settings of course) and it works. Not perfectly, due to the rounding errors during the calculations, but in practice values can be considered equal.
WPF uses System DPI in order to be resolution independent and you need to set actual DPI (real DPI value for current resolution). You need to set DPI in order to help WPF to be resolution free. Finally (and I think very crucially) you have do one more thing, at least on Windows XP, you need a restart in order to enable your DPI settings with the new value. If you do not (as I did), WPF still make the calculations wrong and draw in different size.
These are my understanding and results from the tests I did, but I cannot claim they are absolute. I just want to share it with the people who may find this information useful. Please comment/edit my post if you find any error or think that needs improvement.
What is the meaning of the statement below:
My system resolution is 1024 x 768 at 96 DPI
I am not able to understand the internal maths that when we increase the DPI at fixed resoltion the user interface developed in VC++/MFC or C# /Winform application expands ( look larger then that at 96 DPI ).
For example we develop user interface at 96 DPI which mean 96 dots per inch. Now when we increase the DPI then we are increasing the Dots per inch then user interface should look compressed instead of enlarge.
I am doing it at windows 7 machine
Please help!!
My system resolution is 1024 x 768 at 96 DPI
This means that your computer thinks that your monitor has 96 dots (pixels) per inch (at this resolution). When a program does graphical calculations, it uses this setting to convert between real lengths (in inches or centimetres) and pixels.
This will work out correctly if the 96 DPI setting matches your monitor (i.e. the display area is 1024/96=10.67 by 768/96=8 inches).
Why do things get larger when you increase this setting? Let's say we want to make a button 1 inch high, and your monitor's real DPI is 96, but you have set it to 150. One inch times 150 dots per inch gives us 150 pixels, so we will draw our button 150 pixels high. But our monitor's real DPI is 96, so this appears as 150 pixels / 96 dpi = 1.56 inches high.
there is no "DPI"-setting for your monitor, this device only knows about pixels. DPI = either printers or preformatted documents which need to be viewed in special devices. You CAN, however, calculate how many pixels would be needed to display something with the physical size (hence DPI) of X ... which is a rather unprecise calculation, by the way.
If you're calculating physical sizes you're either developing computer-games, writing your own printing-driver or need to fulfill extraordinary project-tasks
if i put everything in viewbox container then my wpf apps will be resolution independent or do i need to do anything else. please help with concept.
Scale elements accordingly to the available screen or medium size
If your desire is, to allways fill some room of the screen or output device, independently of the metrics, using the viewbox is a good choice. If you have a big monitor, you will have a big element, if you have a small paper, you will have a small print out of the same element.
With the Stretch-property of an image you have a similar possibility only for pictures.
Make elements on every device equaly sized
WPF is designed "resolution independent". The goal of this resolution indepency is, that if you design an element to be 15 inches, then it will be on every output medium this 15 inches, independently of the resolution of your output device. Calculaction and specification of dimensions is done in "device independent pixels" (DIP) which you can convert to centimeters or inches without having specific knowledge about the output devices resolution.
96DIP == 1inch == 2.54cm;
1 inch == 96DPI;
1 cm == 37.8DIP;
If want to use this resolution indepency, you can set fixed values (in DIPs) to your elements. On a large monitor then your element then maybe only uses a small part (e.G. 15inches), and on a small monitor it fills the whole screen (also 15inches).
WPF is resolution independent without any extra tricks at all. If you host legacy controls (non-WPF controls) then this may break for them, but WPF itself is resolutions independent and vector based.
Viewbox has nothing to do with resolution independence.
Resolution independence means, controls you specify can be drawn on different resolutions while keeping scale. So you can use display that has 10x bigger density of points, but controls will still look same to you.
And like it was said, WPF itself was designed with this in mind, you dont have to do anything.
I'm learning about WPF. WPF uses device-independent pixels. But I can't really understand them. Why are they better than device-dependent pixels, if most other apps are device-dependent and WPF apps aren't? Would they stick out?
The advantage of device independent pixels is that when specifying a UI you can determine the size that UI components will appear on the user's device, regardless of the user's screen resolution. Unfortunately, it's not quite as simple as that, as it requires the user to have various settings set 'correctly', and it can be overridden by a user who wants to change the resolution of their device (e.g. a partially sighted user who wants to run at a low resolution to make text easier to read).
In addition to the other link posted, you can also check out this one:
Is WPF Really Resolution Independent?
Note that you can turn on snapping a control to device pixels with the SnapsToDevicePixels set to true to avoid the blurriness that occurs when a horizontal/vertical line is drawn on the boundary between two device pixels.
Before understanding device independent unit, it is required to understand what DPI is. DPI is dots per inch, that means there would be certain number (96 usually) of pixels in an inch . But what is important to understand is in Win32 environment this inch is not fixed in size as a physical inch. So when the number of dots increases / decreases by changing the resolution there would more / less number of dots in an inch as a result the "inch" size increases or decreases.
However in case of WPF the inch size is as good as a physical inch as a result every time the DPI changes the system adjusts it self accordingly.
It's about UI and font scaling depending on the system's DPI setting:
Not all applications are DPI-aware: some
use hardware pixels as the primary
unit of measurement; changing the
system DPI has no effect on these
applications. Many other applications
use DPI-aware units to describe font
sizes, but use pixels to describe
everything else. Making the DPI too
small or too large can cause layout
problems for these applications,
because the applications' text scales
with the system's DPI setting, but the
applications' UI does not. This
problem has been eliminated for
applications developed using WPF.
WPF supports automatic scaling by
using the device independent pixel as
its primary unit of measurement,
instead of hardware pixels; graphics
and text scale properly without any
extra work from the application
developer.
This is taken from the link Kishore provided. (http://msdn.microsoft.com/en-us/library/ms748373.aspx)
I read and article talking about moving beyond 960px width for websites. This width is considered optimal since it is divisable by 3, 4, 5, 6, 8, 10, 12, 15, and 16 (no these aren't the Lost Numbers ;-) ) This helps in grid placement and this really doesn't apply to Silverlight apps but I started to wonder what would be optimal.
What would you recommend as the optimal resolution for a Silverlight app?
I'm thinking 960 x 720 would be in the range of almost every monitor out there.
Or maybe the next step down 720 x 540?
The optimum for a Silverlight application would be whatever the user has the resolution set to - the application scales accordingly.
Refer to this MSDN article for more information.
Personally, for the type of apps I do, I wouldn't bother to try and support people with less than 960px of available space. There is always going to be somebody with outdated tech/monitor size...and 960 is probably going to cover 95% or more of any target audience for me.
One thing you need to be careful of is that a lot of laptops have a maximum vertical resolution of 800 pixels, and once you add the title bar, toolbars, start menu, status bar, etc. you're actually very easily below 600 pixels for vertical screen space. It can be even worse with netbooks. I've seen too many Silverlight apps that are 600 pixels or more vertically and they get cut off because the div isn't set to the proper height to make the page scroll.
I agree with Anthony that you should just let the app resize itself. Just make sure that the app and all of the controls scale well (nothing gets cut off or stretched too big or too small) when going to a really small size to a really big size.