none
Changing metro app window size/screen resolution

    Question

  • I'm working on a metro app/game in C# and I'd like to be able to change the windows size/screen resolution from within the app itself.

     

    The default behavior is that the app starts up with the default screen resolution, but in some cases that's not ideal (1920x1080 on a slower machine), so I want to set the resolution the app uses.

     

    Windows.UI.Core.CoreWindow has a Bounds property, but it's only get-able, not set-able. I can't seem to find an api for this, does anybody know if I'm missing something?

     

    (The comparable win32 api would be something like SetWindowPos, to change the extenst of the window).

     

    Thanks,

      Borut

    Sunday, February 05, 2012 11:16 PM

Answers

  • Hi Borut,

    Metro style apps cannot control the screen resolution or their window size. They will generally run full screen, but may run snapped or filled at the user's option.

    If your app cannot render at that resolution it could render into a smaller element within its overall space.

    --Rob

    • Marked as answer by BorutP Tuesday, February 07, 2012 5:24 PM
    Monday, February 06, 2012 10:02 PM
    Owner

All replies

  • Hi Borut,

    Metro style apps cannot control the screen resolution or their window size. They will generally run full screen, but may run snapped or filled at the user's option.

    If your app cannot render at that resolution it could render into a smaller element within its overall space.

    --Rob

    • Marked as answer by BorutP Tuesday, February 07, 2012 5:24 PM
    Monday, February 06, 2012 10:02 PM
    Owner
  • You are by no means the only developer outside Microsoft wanting to figure what approach to take in the screen resolution model of Win8 Metro style apps. On the other hand resolution switching as done traditionally in Win32 has never been ideal for UX and at one time was a good way to enable customers to discover graphics driver bugs.

    As Rob suggested, one approach that can be ok for larger screens is to only use a part of the display surface for the main app/game window. The second is to upscale where upscale graphics hardware performance is adequate - particularly useful for physically smaller displays e.g. a 10" Tablet where a small active area would be unacceptable.

    It looks likely that higher DPI screens will start appearing this year (at last!) so upscaling is a good choice to allow for some future proofing (we have to assume no vendor would be foolish enough to release products without adequate graphics hardware support).

    I expect to use a mixture of both approaches based on run time measurement of display device characteristics as well as any info revealed by api. 

    A complete unknown to those of us outside Microsoft is what we can expect from entry level ARM devices. On a positive note, at least we don't need to concern ourselves with legacy hardware here,

    Other questions - whether Windows 8 is supported as an upgrade to older systems with low performance graphics, or whether Windows 8 App Store will allow us to manage the expectations of users with low performance hardware - integrated graphics has come of age but some of the older ig chipsets aren't over exciting.

    Personally I'd like to see some reference platforms defined and ideally made available at test centres so we can measure performance but I've not seen any program announced by Microsoft yet. Indeed until we have a beta not sure would be especially helpful at this point anyway to those of us without much leisure time.

    Bob Richmond

    Tuesday, February 07, 2012 11:15 AM
  • The notion that somehow changing resolutions for fullscreen apps is the cause of poor UX is unfounded, it's merely a coincidental symptom.

    It's really the only way for end users to control game performance on incredibly variable hardware. Removing that option and simply forcing a game developer to render at a lower buffer and upscale (using a smaller viewport was obviously never an option - what user only wants to use half their display?) - all this does is make the developer do more work every single time, and make it harder to write cross platform apps (a heavily recurring theme with Metro). 

    Meanwhile there's no way (as far as I can tell) to get the physical size of the device, in order to maintain consistent UX (button size being measured in real world size to guarantee finger-width size buttons), which just confirms the api is not forward-looking at all (and which I would have happily sacrificed some features for).

    Tuesday, February 07, 2012 5:24 PM
  • Hi Borut,

    Metro style apps support scaling. See Guidelines for scaling and the Scaling sample.

    Applications should scale appropriately without needing to change system settings or breaking out of the Metro view.

    Typically games tune their rendering to use fewer or simpler objects if they can't keep up with the full screen view.

    --Rob

    Tuesday, February 07, 2012 8:50 PM
    Owner
  • Borut,

    I agree completely with your comment on cause vs. symptom on UX, although I've seen enough grief from the symptoms! I will personally continue to set resolution on Win32/Direct3D product, indeed it is the only way with a user base with a wide variety of (often aging) hardware.

    Right now waiting to see what gaps if any remain in the Metro API by Beta before getting too worked up. Also looking forward to seeing benchmarks, and as mentioned before, clear guidance on reference hardware etc. I'd prefer Microsoft were fairly aggressive in defining minimum graphics requirements for Metro though I'm not optimistic that will happen. Hopefull better than the Win32 space though. Agreed we will all need to be able to adapt to physical screen dimensions its a no brainer especially for touch and the greater upcoming range of screen sizes and pixel densities compared with Win7 era hardware.

    Looking like my own first Metro games project is C++/Direct3D so at least spared some of the C# specific performance questions this year, my main concern there is ARM, e.g. specs for entry level floating point and graphics hardware performance. Aside from that project I remain mainly C# so hope you continue to raise performance and games issues here.

    Bob

    Wednesday, February 08, 2012 1:23 PM
  • Going through those guidelines for scaling, it looks like that's only for UI controls/XAML?

    Not very useful for games, since they will always have custom animated UI widgets.

    Also that page doesn't mention anything about touch input scaling - that's the primary need for knowing the physical screen size (so controls and thresholds for gestures like dragging can be custom-handled correctly).

    Tuesday, March 13, 2012 6:45 PM