Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Displays Graphics Windows Hardware

Windows 8 Has Scaling Issues On High-PPI Displays 171

crookedvulture writes "High-PPI displays are becoming increasingly popular on tablets and notebooks, but Windows 8 may not be ready for them. On a 13" notebook display with a 1080p resolution, the RTM version of Win8 scales up some desktop UI elements nicely. However, there are serious issues with Metro, which produces tiles and text that are either too small or too large depending on the PPI setting used. That setting, by the way, is a simple on/off switch that tells the OS to 'make everything bigger.' Web browsing is particularly problematic, with Internet Explorer 10 introducing ugly rendering artifacts when scaling pages in both Metro and desktop modes. Clearly, there's work to be done on the OS side to properly support higher pixel densities."
This discussion has been archived. No new comments can be posted.

Windows 8 Has Scaling Issues On High-PPI Displays

Comments Filter:
  • Did the MS product mgmt, engineering and test orgs not think to try this out on a standard desktop machine with the high res monitors pretty much everyone uses these days? Incomprehensible!
    • Re:Wha...? (Score:5, Insightful)

      by Sir_Sri ( 199544 ) on Wednesday September 26, 2012 @01:49PM (#41467125)

      1080p is just 1920x1080 - that part almost certainly works fine. It's that pixel density has, for years, been within a fairly narrow range (22-27 inch displays all maxing out at 1920x1200 or 1920x1080). The problem is pixel density is now increasing, think apple retina displays, and that's a problem most of us on the software side were never expecting and aren't used to having to cope with. At least not for desktops/laptops (phones is another matter because they are a rapidly maturing product used in a completely different way).

      Besides that, different groups will have people who are more or less aware of this problem and trying to deal with it. Microsoft *should* have testing labs for all of these different things, and feedback about a very uneven experience should have moved up and down the chain. But as someone who writes games for a living, most of the stuff I have done in the last 5 or 6 years would look like shit on a 13 inch display at 1920x1080. Everything would be too small unless the screen is 10cm from your face. That's the catch here, we've designed for a single pixel to take up a certain fraction of your personal field of view, suddenly higher density displays come along, to which we initially ask, why, was there something wrong with the old pixel densities? Is this technology actually better or is it just going to be a method to sell expensive video cards. These new displays people are physically positioning the way their old setups were, but well, all of the assumptions about field of view get tossed.

      • Yeah, is there any OS that handles this quite right?

        I recently bought one of those korean ebay 2560x1440 27" displays and it looks great...but not *everything* looks great on it. Win7 UI elements scale pretty well with the built in settings, but if you turn off "Use XP compatible scaling" (or similar), applications start doing really stupid things. I believe that what they do with any application that does not report it is dpi-scaling-aware (and unfortunately, just because it says it is, doesn't mean it

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Yes. There is something VERY wrong with old pixel densities.
        Aside from the idea that I had a 1600x1200 display TWENTY YEARS AGO and since then WE'VE GONE BACKWARDS, I can offer a lot of very good reasons.

        1. Clearer pictures. My phone can snap images many times larger than the effective res of my monitor. My monitor should not be the bottleneck.

        2. Font smoothing - Subpixel rendering is an ugly hack and makes things look like garbage (If it looks good to you, you need glasses. Yes. You do.) You really need "

        • Sadness (Score:3, Insightful)

          by SuperKendall ( 25149 )

          Aside from the idea that I had a 1600x1200 display TWENTY YEARS AGO and since then WE'VE GONE BACKWARDS

          You are so right there... I would not have believed 10 years ago that newer large monitors I bought would feature worse resolution. Yet that has been the case for years with monitors that align to 1080p...

          Thankfully we are finally starting to break free and actually get more resolution at last, as with the Korean displays people have mentioned here... going to get one of those soon I think.

        • by Sir_Sri ( 199544 )

          What 1600x1200 display did you have 20 years ago? A 20 inch CRT? That's roughly the same pixel density as a 22inch 1920x1200 or 1920x1080. Aspect ratios screw things up a bit. Also, part of making shit cheaper has been making it lower quality, that's a separate problem.

          In 1992 we were still looking at 15 inch 1280 x1024 displays, which is about the same as today, give or take an aspect ratio.

          To your specific points

          1. Clearer pictures. My phone can snap images many times larger than the effective res of my monitor. My monitor should not be the bottleneck.

          And? How well can you tell the difference for most tasks? If you quadrupole the number o

          • by LocalH ( 28506 )

            Pixel densities where chosen way back in the 90's precisely because they were pretty much good enough. Apple's 'retina' display aims to be the point at which there is literally no further benefit from more pixel density, but 'no further benefit' and 'good enough for virtually every task' are not the same thing.

            I suppose that the print world should drop down to 100ppi or so, since that's clearly "good enough" for you (reference for the number: a 17-inch laptop panel at 1600x900 is roughly 109ppi, and if you bump that up to 1680x1050 then you'll be getting rougly 114ppi). Some of us want our screens to look like the printed page, and until then things aren't "good enough" but merely "mediocre".

            If you think a "retina" display is "slightly better looking" then you clearly haven't used one at length. I use my iPod tou

      • Re:Wha...? (Score:5, Informative)

        by JDG1980 ( 2438906 ) on Wednesday September 26, 2012 @02:11PM (#41467403)

        That's the catch here, we've designed for a single pixel to take up a certain fraction of your personal field of view, suddenly higher density displays come along, to which we initially ask, why, was there something wrong with the old pixel densities?

        Yes, there was. The existing low-density displays require ugly (and often patented) hacks like hinting and subpixel rendering to display fonts at normal point sizes. When the pixel density is increased enough, this all becomes unnecessary. And it looks a lot better when it's done right. Have you ever tried using the new iPad? To me, it was a revelation: with a web page or PDF fully zoomed out, the letters were still incredibly sharp and clear, with none of the usual "cloudiness" that results from standard anti-aliasing techniques.

        ClearType on Windows is very nice, but it's still just a hack compared to real high-DPI display. I am looking forward to cheap 4K TVs in smaller sizes (32" or so) so that I can use one of them as a desktop monitor. We've been held back by repurposed 1080p HDTV panels for too long.

        • by Sir_Sri ( 199544 )

          Have you ever tried using the new iPad?

          Yep. I can't fathom why anyone in apple design thought sticking on a high pixel density display was a good idea. It doesn't look appreciably better than a regular display and requires a lot more computing power to drive applications natively. Which is why no one else seriously tried something so stupid in the last 20 years.

          Now they're all following along like sheep because apple is doing it, and it certainly makes sense to have standards and so on for larger displays, but there's virtually no benefit for

      • by AmiMoJo ( 196126 )

        The fix is to do what Apple did and simply double the resolution. All your scaling problems go away, just double every pixel of images and render vector stuff like fonts at full res.

        I hope we get 4k displays soon. I would prefer 4k over Apple's intermediate Retina resolution because it is only an effective 1440 pixels wide. 4k gives you an effective 1920 pixels, the same as what I have now but sharper. Panasonic do a 20" 4k display and a few manufacturers have demoed 24/27" monitors, but they are still in t

  • I find it funny... (Score:5, Insightful)

    by K. S. Kyosuke ( 729550 ) on Wednesday September 26, 2012 @01:38PM (#41467005)
    ...that MS has been one of the first to do the "device-independent drawing stuff" with GDI, and yet twenty years later, there's still no working device-independent UI from them.
    • by AmiMoJo ( 196126 )

      To be fair TFA is not comparing like with like. Windows is being asked to scale the display by 125% which is obviously going to lead to blurry images. Apple Retina displays are exactly 2x the previous resolution so have 200% scaling, so there is no blur when scaling images.

      If you install Chrome on MacOS and scale it to 125% it will look just as bad as it does on Windows. There is no escaping the fact that scaling to 125% looks crap.

      Both options have their advantages. 125% scaling on a 13" laptop with 1920x1

    • Microsoft has offered a UI framework with device-independent UI scaling since 2006 - that's WPF. Ironically, to do that fully, it also did the same kind of font rendering that OS X and iOS do (idealized rather than snap to pixels), but users hated it for that.

      Metro apps in Win8 also have strong explicit support for DPI scaling.

      • by narcc ( 412956 )

        Was it possibly earlier? IIRC, Windows GDI was all about device independent scaling since at least Windows 3.1. If I'm missing something, let me know.

        • No, GDI was never about device-independent scaling, it always operated in physical device units (i.e. physical pixels when it came to the screen). You could certainly do it before, but you had to query the system for the current DPI value, and do your own calculations to translate points or inches or whatever it is you were using to physical pixels. There was one exception - CreateDialog - which used "dialog units" in dialog template, which were designed to be device independent.

          Oh, there was also VB, which

  • by Anonymous Coward on Wednesday September 26, 2012 @01:43PM (#41467053)

    I once worked on hardware rendering with a webkit-based browser, and these kind of issues are very common when you're converting between floating-point layout coordinate and integer screen space.
    Some rendering pipelines make it harder than others to deal with, especially if you can't control the behaviour of non-integer pixels at the edge of images. To fix it, you have to visit all the conversion sites and decide how you want to handle the conversion. It gets especially tricky if you're scaling and stitching images together that you've uploaded as multiple textures to get around maximum texture size issues. Concatenated transformations through composition layers can be tricky too depending on what your graphics API does.

  • by chris200x9 ( 2591231 ) on Wednesday September 26, 2012 @01:43PM (#41467055)
    I blame apple...if the wouldn't have released those retina displays high-PPI displays would have never come and windows 8 would have been a huge success. Apple can you not leave Microsoft in peace for one second?!
  • Releases of new operating systems come with a large number of bugs, and that goes with the territory. In general, users are understanding and patient.

    But these seem like alpha level bugs that should have been stomped out ages ago.

    1080p displays are hardly unusual or non-standard. This does not bode well...

  • To be fair (Score:3, Informative)

    by TheSkepticalOptimist ( 898384 ) on Wednesday September 26, 2012 @01:53PM (#41467163)

    This is not a Windows issue but rather the way that developers support High DPI in their apps.

    Way too many developers are still using MFC and Win32 for UI development, which has no concept of High-DPI and requires scaling to be done manually. If the app doesn't even poll for the current DPI of the OS then nothing is going to scale correctly using those antiquated API's.

    WPF automatically adjusts controls to the DPI settings of the OS, however if you don't use vector paths to render UI elements you might see an ugly bitmap stretch here and there. Haven't fully investigated Windows RT (the framework, not the tablet), but I am sure DPI awareness is also a fundamental part of its presentation framework. If a developer throws a 16x16 icon into an app resource, you are going to get and ugly scale.

    When it comes to web pages then its anyone's guess how the web designer will support high DPI. Web pages are still mostly a bunch of static jpg's so scaling up something that looks like a line on regular DPI settings, only to see it smear and blur into a bar as shown in the article is purely the fault of the web page designer.

    I do agree that as a whole Microsoft needs to do a little better job supporting High DPI across their API's, but most of what this article mentions comes from poor app/web design more then anything.

    • Re: (Score:3, Informative)

      It is up to the web browser. The only thing the web master should do is put a CSS if it is a mobile screen to take away some complexity or change the dimensions of the text for readability.

      The web browser is what takes care of integrating the images with the operating system and rendering them on screen. Windows 8 supports high DPI but I am fairly shocked IE 10 which is an excellent browser contrary to past releases of IE does not fully support it. IE 10 needs to be patched asap as it is used in Windows 8 m

    • This is not a Windows issue but rather the way that developers support High DPI in their apps.

      It's still sort of a Windows issue. The complaint the article raises is that there are no fine grained controls for adjusting dpi. The default setting was "too small" but flipping the switch to "make everything bigger" was too large. Also changing this doesn't change things on the desktop side, and adjusting things on the desktop side doesn't change the metro side. This should be reconciled sooner rather than later.

    • Way too many developers are still using MFC and Win32 for UI development, which has no concept of High-DPI and requires scaling to be done manually. If the app doesn't even poll for the current DPI of the OS then nothing is going to scale correctly using those antiquated API's.

      This isn't entirely correct.

      First of all, Win32 does have some very basic support for DPI independence. In particular, the various dialog-related APIs (CreateDialog etc) measure things in "dialog units", which are defined in terms of system dialog font - the size of which varies depending on your DPI setting.

      Additionally, if you write an app in Win32, and you don't explicitly state in your app manifest or via an API call that you are "DPI-aware" (i.e. know how to scale), then Windows will tell your app to r

  • I can't believe modern devices still don't support resolution independent layout, especially on tablets. All they would have to do is design displays to send their ppi as well as their resolution to the computer, then change the operating system to make that data available programs.
    • I think you can already pull DPI from EDID information. However it requires a lot of coding to make the scaling work through the OS and apps properly, so it's not exactly that easy.
      • I think you can already pull DPI from EDID information. However it requires a lot of coding to make the scaling work through the OS and apps properly, so it's not exactly that easy.

        It's not hard either. The GPU does the scaling. On Android (but not on iOS) the font manager takes care of hinting text to the native resolution. OP talked about resolution-independent layout, which is indeed lacking across the board. It's not rocket science for anybody except Apple, who stupidly backed themselves into a corner by relying on fixed size screen resolution.

    • They already do everything that you've mentioned.

      In specific case of Win8, here [msdn.com] is a rather detailed explanation of how it all works, and why.

      • Unless there's something I missed, that article says windows 8 doesn't support resolution independent layout. It says windows 8 does layout in pixels, but scales every thing up for certain devices (they can have scale factors of either 100%, 140% or 180%).
        • If your "pixels" in layout actually get scaled according to DPI, then they are in effect device-independent units (as they are in CSS today, for example).

          It does say that it doesn't scale precisely to your DPI, but rather to one of 100%, 140% or 180% that is the closest match for your actual DPI - which is done to let people use bitmaps, so that they can just provide three versions of those and there wouldn't have to be any stretching which looks awful on bitmaps. XAML stuff is all vectors, though, and it c

  • Honestly Android is the only OS I've seen that elegantly handles scaling to higher resolutions and varying aspect ratios. Hell, the SDK itself gives you many options to make sure your app scales well.

    Owning an ipad 2 myself, I can say that iphone apps scale horribly to ipad, and apple themselves even had a blunder when they changed aspect ratios (lol letterbox phone.) It's no mystery why when they increased the resolution on the ipad 3, they had to evenly multiply from 1072x768.

    Any competent mobile OS shoul

    • Owning an ipad 2 myself, I can say that iphone apps scale horribly to ipad

      It's a simple 2x scaling, but it does have one redeeming aspect - if the images are larger than original size, you get more pixels.

      It's no mystery why when they increased the resolution on the ipad 3, they had to evenly multiply from 1072x768.

      They did not have to but it made everyone's life much simpler.

      Apple themselves even had a blunder when they changed aspect ratios (lol letterbox phone.)

      See? They didn't have to @2x new resolutio

    • When microsoft decided "let's make windows work for mobile platforms" and created metro, they should have taken this into consideration, yet oddly enough, they didn't.

      Maybe it wasn't on the Powerpoint slide.

  • there was only one true screen resolution: 640 x 480

    Back then the only thing you had to worry about was whether to support 256 colors or stick with 16.

  • by Misagon ( 1135 ) on Wednesday September 26, 2012 @02:03PM (#41467317)

    The Metro APIs were designed for web front-end programmers, not people who write for real GUI toolkits. You can build quite competent Metro apps in HTML and Javascript, and if you reach any limits, your web shop could hire a third party to write a module in C# or C++ to work around it.

    The API for web programmers includes also rules that that apps should be made for a finite set of fixed screen sizes. Not resolutions -- screen sizes. Metro was never designed to be scalable.

    This is not only a Windows problem, though. MacOS X on Retina(tm) displays is just as bad, but there the OS draws everything twice as big to begin with and scales down if needed when compositing windows. Apple never cared about hinting anyway, so all controls and labels are just as fuzzy scaled to 125% as always.

    • You realize that you don't have to write Metro apps in HTML and JavaScript, right? There's also the XAML route, with C++, C# or VB as languages.

  • by MaWeiTao ( 908546 ) on Wednesday September 26, 2012 @02:10PM (#41467389)

    So Microsoft is being blamed for graphical limitations they had nothing to do with. From what I'm seeing the problem isn't that elements within the GUI are scaling poorly, it's that designers didn't account for the fact that some day someone might want to blow up their graphics on a much higher resolution display. It's ridiculous and unfair to blame Microsoft for this considering this would affect any high res display in any OS. What do you think happens when you run an iPhone 3 app on an iPad? By the logic displayed in this article that should also be Apple's fault.

    Anyone with the most trivial experience in resizing photos will understand that this is an unavoidable problem. There's no practical way to fix it unless you rebuild the app to account for wildly varied resolutions. You could use vector art, but it's not a realistic solution for a lot of things. There's no elegant solution but hopefully the pixel density is high enough that these artifacts aren't all that obvious. This is one of those situations where it's on the third party developers can only fix the problem after it's arisen. Microsoft can't fix it for them.

  • How is this described only as a Windows problem?

  • IE10 HAVE RENDER ISSUES ME NO BELIEVE.

    I get that it's really hard to make a browser do everything right, but if you're going to push IE as such a major competitor to other browsers, maybe make it less of a steaming pile? The web browser is basically a commodity nowadays, drawing things right is just about the only thing that matters.

  • The issue comes into being most likely due to off-by-a-fraction errors when doing non-integer scaling of multiple elements.

    One solution is just to get all your fractions right across the entire rendering pipeline. That is hard, and maybe impossible in some cases.

    An easier solution is just to render to a canvas that is an integer multiple of the "base" or "expected" case, then finally apply a single scaling from that canvas to the display size at the last moment before the image is displayed.

    For instance, l

  • Large displays too. Look how much space Windows 8 wastes on a 20 inch monitor rendering overly large tiles. People with large monitors and mice and keyboards should be able to zoom out and see more tiles at once if they so wish.

Your password is pitifully obvious.

Working...