none
Resolution Independence?

    Question

  • WPF claims to be resolution independent.  This independence is based upon a couple of assumptions.
    1. WPF Device Indepenent Unit (DIU) is 1/96th
    2. User's monitor has a physical dpi of 96
    3. User is running at a native resolution (lcd) where display dpi is 96 or
    4. User's operating system rendering dpi is set to the display dpi of their monitor

    Here are the problems....
    1. My Users may or may not have a monitor that has a physical dpi of 96
    2. My Users do not want to be forced to run at a native resolution
    3. Vista does not allow the dpi to go below 96.  (which has obvious implications to the native use of WPF in Vista)
    4. Ability to determine User's monitor configuration is sketchy at best.

    We want to use WPF for an suite of enterprise applications.  Our Users are running XP and Vista.  However, we do not want to force hardware upgrades or force people to use native resolution.  Anyone have a suggestion? 

    Can we change the DIU for an instance of an application?

    We are not resolution independent if we are hardware dependent. 


    Monday, December 17, 2007 5:35 PM

Answers

  • What I'm suggesting is that you assume that the display area is at least 1024 by 768 device-independent units, because device-independent units are what you'll be working with in WPF.  Under this assumption, your app will be fine running on:

     

    a 1024 by 768 monitor with a setting of 96 DPI

    a 1280 by 1024 monitor with a setting of 96 or 120 DPI

    a 1600 by 1200 monitor with a setting of 96 or 120 or or 144 or 150 DPI

     

    etc.

    Basically you're assuming that the display surface is at least 10-2/3" wide by 8" high.

     

    (And don't tell me that the monitor is not that size!  The actual size of the monitor is irrelevant!  Forget about "native resolution" and the physical size of the monitor.  These numbers are irrelevant.  They're not something the application can even determine, and they do not factor into application design.)

     

    What you can properly assume is that 8-point type is readable on the screen, but 9 or 10 point type might be more suitable for comfortable reading. That's really what this DPI setting is all about.  The user is suppose to set the assumed DPI to a level where 9-point type is comfortably readable.

     

    OK, now you have a minimum total screen area in inches, and a target point size for text.  What you can fit on the screen is entirely determined by those two factors.

     

     

     

     

     

     

    Tuesday, December 18, 2007 9:32 PM

All replies

  • The Windows user is ultimately responsible for setting an assumed resolution of the video display.  This is done in the Display Properties applet.  Commonly this assumed resolution is 96 or 120 DPI but it could be set higher.  This has been the case for several past versions of Windows and it remains unchanged in Vista.

     

    The assumed resolution is independent of the actual resolution of the monitor. The user can *try* to set the assumed resolution equal to the actual resolution, but there is little reason for it. But again, nothing has changed with Vista.

     

    WPF programming involves device-independent units of 1/96th inch.  If the assumed resolution of the video display is 96 DPI, then WPF DIUs correspond directly with pixels.  If the assumed resolution of the video display is 120 DPI, then WPF DIUs are equal to 1-1/3 pixels.

     

    Functionally, there is no real change.  For decades, Windows programmers have either been obtaining the assumed resolution of the video display or using mapping modes based on this assumed resolution.  The whole process is somewhat more convenient in WPF than in previous Windows APIs, but it's functionally the same.

     

    The WPF DIU is only something the programmer sees.  It does not affect users at all.  Users are not required to make any adjustments to accomodate the WPF DIU.

     

     

     

     

     

     

     

     

    Monday, December 17, 2007 7:59 PM
  • Mr Petzold -

    Thank you for responding.  I've read your blog posting on this matter.

    Our issue with WPF is the way the Resolution Independence plays out to the User.  If my User is working with a properly configured environment (physical dpi of 96 at native resolution), then my UI appears as I designed it.  However, if they lower their resolution, my WPF UI content no longer fits on screen.  Our User has little concept of system dpi, physical dpi, Win32 vs WPF rendering, ect... they just know our app doesnt work on their box, and its our fault. Smile

    In a Win32 application, we could design for the lowest supported resolution and know our system would be usable.  For WPF, we are designing for the properly configured system... something we cant be assured of by our User base.

    I figured there wouldnt be a way to alter the DIU.  The reason we considered altering the DIU is... the DIU is making the incorrect assumption, imo.  If the User is on a 17" 1280x1024 native res monitor with a physical dpi of 96, and then they change their resolution to 1024x768, the displaying dpi now becomes 75dpi.  The User could change their dpi to 75 (only works on XP), or I could programmatically alter the DIU to 1/75th and my UI would fit again.

    We are looking for some programmatic direction that allows our Users the display freedoms they are used to (changing resolution, using whatever monitor is handy, ect...), while ensuring our application displays correctly for all of their configurations. 

    Any ideas or thoughts on the subject?

    Thanks
    StephenW

    Monday, December 17, 2007 8:30 PM
  • I don't know if I'm misunderstanding your problem, but could you simply wrap your UI in a Viewbox?  Then your whole app would scale to whatever size.

     

    Sometimes a Viewbox doesn't fit what I'm trying to do, so I just use the Grid + Margins to property grow and shrink my UI within a given space.

     

    -Jer

     

    Monday, December 17, 2007 8:37 PM
  • I'm believing that screenshots of this problem in action would be very helpful.

    A viewbox would be an interesting solution, if it works, but may give some aspect ratio problems. When a user resizes the window, the content would change size (zooming and shrinking) rather than the layout stretching to take up more room. Size consistancy between pages in the application would be nil.
    • Proposed as answer by DJ 1984 Monday, May 14, 2012 11:56 AM
    Monday, December 17, 2007 8:56 PM
  • Jeremiah -

    I'll look into the Viewbox as an option.

    Margins and Paddings wont work for this issue.  Here is a posting on this issue that describe it accurately.
    http://www.wpflearningexperience.com/?p=41
    Monday, December 17, 2007 9:04 PM
  • If you set your Viewbox Stretch property to Uniform, you can avoid the aspect ratio issue.  *edit* Or "UniformToFill" + a scrollbar to scroll the portion of the UI that maybe invisible when scaled*edit*

     

    From what I get out of WPF development, it is up the developer to make sure the UI scales properly to fit different monitor resolutions, but WPF gives you all the tools to make it more simple than in Windows Forms.

     

    As for the DPI setting in Windows...Personally I have never touched this setting...ever.  Well maybe once for some elderly folk Smile.

     

    Hope you get your project working right!

     

    -Jer

    Monday, December 17, 2007 9:13 PM
  • If anyone would like to see this issue in action, take any WPF application and run it at different resolutions.  Measure any control (with a ruler) and you'll find the controls to be of a different size at different resolutions. The factors I stated earlier have to align for the control to be the same size at any configuration.
    1. System's rendering dpi
    2. Monitor's physical dpi
    3. Screen Resolution
    4. WPFs Device Independent Unit

    (bump)

    Monday, December 17, 2007 11:11 PM
  • It has always been like this.  Windows programs have always scaled their controls based on metrical mapping modes or the size of the system font, and these things have always been based on the assumed resolution of the video display, which has never (except by accident or compulsive users) been equal to any physical dimension.

    Tuesday, December 18, 2007 12:09 AM
  • What an absurd idea. Of course the size of things changes when the user alters their resolution but not their DPI setting. If your program were somehow able to "alter" the DIU, the best case is that your program would shrink (but appear to remain the same physical size) and a WPF pixel would no longer fit inside a physical pixel, resulting in a loss of detail/clarity and potentially illegible text.

     

    This is a complete non-issue and isn't something you should be worrying about. You're not going to somehow "fix" the dilemma of the user playing with the hardware settings so much that your app doesn't look quite right. WPF goes a lot further towards fixing this than anything has before, though.

     

    Plus, users should always run at the native resolution of their screen. WPF means they can do this and everything will appear as it should, with greater clarity. Only with non-dpi-aware applications and users with sight difficulties is there a conceivable excuse for not running at native resolution.

    Tuesday, December 18, 2007 12:13 AM
  • Thanks for the responses.

    I am trying to understand the best way to present a standard interface to our users.  We have a rich, data intensive application suite where screen real estate is scarce and design integrity is important.  I also have existing Users and hardware to contend with.

    In the past, we choose the 1024x768 resolution as our lowest common denominator for Win32 applications, independent of monitor size.  This wont work for WPF due to the use of the DIU, at least for LCDs.

    Assuming my interface is designed at 96ppi and 1024x768 is my standard resolution. 
    15" 85ppi Monitor - WPF elements are 11% larger
    17" 75ppi Monitor - WPF elements are 22% larger
    19" 67ppi Monitor - WPF elements are 30% larger

    For WPF, I think the lowest common denominator should be the native resolution of a monitor.  However, not all monitors native resolution is 96 ppi.  A little cross-reference with newegg.com and wikipedia...
    17" 1280x1024 96ppi has 48 results
    19" 1280x1024 86ppi has 52 results
    19" 1440x900  89ppi has 46 results
    20" 1680x1050 98ppi has 17 results
    22" 1680x1050 40ppi has 40 results

    68% of new monitors are below 96ppi.  27% of new monitors are 10% smaller than 96ppi, and this percentage represents the cheaper 19" 1280x1024 that are very common.

    51 of the 100+ monitors that are "Certified for Vista" are below 96ppi.  Remember that Vista doesnt allow the User to drop their dpi below 96. 

    The good news is that all current laptop monitors have a higher ppi than 96.  The bad news is that these values represent what is on sale today, and who knows about the current Users.

    Here is what I dont know.  I dont know how CRTs are affected.  This post is about LCDs are they are much more common today.  I also cant remember, offhand, how Win32 apps behave.  I've worked with .Net 2.0 Winforms and I know they have some scaling, but it escapes me and I dont want to experiment.

    I dont like the fact that people using LCDs will not be able to change their resolution.  However, it seems that requiring the native resolution and building a 10% buffer space into the design will provide us the most flexibility.

    Thoughts?

    Tuesday, December 18, 2007 4:35 AM
  • I am having a difficult time visualizing your challenge.  I just tested our WPF application on 1920x1080  LCD (window maximized), then changed it from its native resolution to another resolution of the same aspect ratio (1280x720) and the WPF application still looked correct and scaled according to how we have our layout setup.  I did the same on a CRT with a 4:3 ratio and fidelity and scaling were not an issue.

     

    I admit that I am totally ignorant about the effects of monitor DPIs and screen resolution, but with: The default DPI windows has (96), keeping monitor resolutions at the correct aspect ratio and designing your WPF layout with scaling in mind, you should not really have any issues (at least I havent experienced any issues).

     

    Sorry I couldn't help,

     

    -Jer

    Tuesday, December 18, 2007 7:10 AM
  • Suppose a Win32 program wants to draw a ruler on the screen.  It calls GetDeviceCaps with LOGPIXELSX and LOGPIXELSY to get the resolution set by the user, and each inch that it draws is that many pixels.  Or, it sets the mapping mode to MM_LOENGLISH and draws 100 units per inch.

     

    A WinForms program wants to draw a ruler on the screen.  It obtains the DpiX and DpiY properties of the Graphics class and draws that many pixels per inch. Or it sets PageUnit to GraphicsUnit.Inch and draws in units of inches.

     

    A WPF programs wants to draw a ruler on the screen.  It draws 96 units per inch.

     

    In all these cases, for any particular machine, the ruler is exactly the same size, and it's the same size as the ruler displayed by Microsoft Word.  Of course the ruler is going to be different sizes on different machines.  Connect the machine to an overhead projector and the inches on the ruler are more like feet!

     

    If the worst display you'll be targetting is 1024 by 768, you should assume that any display of that size is set for 96 DPI, and you should keep coordinates and sizes within that range.  The program will look pretty much the same on a 1280 by 1024 display set for 120 DPI.  That would be consistent with how you'd do it with Win32 or WinForms.

     

    But WPF has several features that let programs adapt to the display size.  You should work with those features rather than believe that they're a hindrance. Give users with larger screens a benefit for spending the money.

     

     

     

     

     

    Tuesday, December 18, 2007 2:15 PM
  • Jeremiah -

    Thanks for your time.

    I assure you the behavior I am describing is real.  For the most part, our application handles the resolution changes cleanly.  However, there are a few data entry pages where we make heavy use of minwidths.  At lower resolutions, the layout of these fields are driven off page.

    This posting has graphics about the issue: http://www.wpflearningexperience.com/?p=41

    Everyone has stated quite clearly that this isnt a WPF problem and I dont disagree with that.  I do think the "WPF Resolution Independence" yields a new twist to our software design and construction that we were not previously considering.

    SW
    Tuesday, December 18, 2007 2:24 PM
  •  Charles Petzold wrote:
     

    If the worst display you'll be targetting is 1024 by 768, you should assume that any display of that size is set for 96 DPI, and you should keep coordinates and sizes within that range.  The program will look pretty much the same on a 1280 by 1024 display set for 120 DPI.  That would be consistent with how you'd do it with Win32 or WinForms.

     



    Mr. Petzold -


    I respectfully disagree with that statement.  The worst case scenario for me is a 19" native 1280x1024 lcd that is set to a resolution of 1024x768.  I understand that the User shouldnt do this, but they will.  Also, I didnt find a native 1024x768 96ppi monitor on newegg.com...  I question their availability.


    Suppose I can prevent the User from changing their resolution.  I still do not agree that I should be designing for a 96ppi monitor.  The research I provided earlier states that the market is full of monitors that are not 96ppi.


    What do you think about targeting a monitor with 86ppi?  If we assume this monitor to be our lowest common denominator, then any monitor with a higher dpi will provide us with positive scaling.


    Tuesday, December 18, 2007 3:29 PM
  • What I'm suggesting is that you assume that the display area is at least 1024 by 768 device-independent units, because device-independent units are what you'll be working with in WPF.  Under this assumption, your app will be fine running on:

     

    a 1024 by 768 monitor with a setting of 96 DPI

    a 1280 by 1024 monitor with a setting of 96 or 120 DPI

    a 1600 by 1200 monitor with a setting of 96 or 120 or or 144 or 150 DPI

     

    etc.

    Basically you're assuming that the display surface is at least 10-2/3" wide by 8" high.

     

    (And don't tell me that the monitor is not that size!  The actual size of the monitor is irrelevant!  Forget about "native resolution" and the physical size of the monitor.  These numbers are irrelevant.  They're not something the application can even determine, and they do not factor into application design.)

     

    What you can properly assume is that 8-point type is readable on the screen, but 9 or 10 point type might be more suitable for comfortable reading. That's really what this DPI setting is all about.  The user is suppose to set the assumed DPI to a level where 9-point type is comfortably readable.

     

    OK, now you have a minimum total screen area in inches, and a target point size for text.  What you can fit on the screen is entirely determined by those two factors.

     

     

     

     

     

     

    Tuesday, December 18, 2007 9:32 PM
  •  Charles Petzold wrote:

    What I'm suggesting is that you assume that the display area is at least 1024 by 768 device-independent units, because device-independent units are what you'll be working with in WPF.  Under this assumption, your app will be fine running on:

     

    a 1024 by 768 monitor with a setting of 96 DPI

    a 1280 by 1024 monitor with a setting of 96 or 120 DPI

    a 1600 by 1200 monitor with a setting of 96 or 120 or or 144 or 150 DPI

     



    Thanks for everyone's responses.

    C. Petzold is correct (not a surprise Smile ).  The physical dpi of the User's screen has no bearing on the way we develop our UI.  If we develop for a specific resolution (or DIU), any monitor that can display that resolution will properly display our UI. 

    There is a good reason why this thread was started.  Many of the screens in our application appeared to scale incorrectly when running at a lower, non-native resolution.  The cause of this had nothing to do with WPFs rendering engine or the variation in pixels-per-inch of our hardware.  This issue was caused by a machine not having the font installed that we were using.  When this happens, WPFs fallback mechanism is to find a similar font and use it.  The similar font found was a different size, which affected our layout negatively.  We were developing the app for 1024x768 - but we mostly ran it in 1280x1024... so we didnt catch the issue.

    This blog posting, while very informative, can be a bit misleading on the subject of WPF Resolution Independence: http://www.wpflearningexperience.com/?p=41

    BTW - the Petzold quote atop this message is a great information.

    Thursday, December 20, 2007 2:40 AM