Dell Precision M3800 Owner's Review

Well I believe you mentioned you couldn't tell a difference between the sharpness of a Retina MBP and non-Retina, in which case I can't imagine this panel would be any different; the PPI is the same, it's just got more horizontal resolution because it's a 16:9 rather than 16:10 panel. If you spend a lot of time viewing off-angle then I can totally see the desire for better viewing angles, but even there unless I was CONSTANTLY in meetings in that situation, I wouldn't even consider FHD rather than QHD+ because of the dramatic sharpness difference. But again, the difference is clear as day to me, like DVD vs Blu-ray or SDTV vs HDTV.

 

Well, I do spend A LOT of time in meetings these days. The "benefits" of moving up, I guess...

 

A note on scaling for those thinking about purchasing this system. You can check it with your apps yourself, now, on your existing system; you don't need a high-DPI screen. Go to Windows scaling settings and crank up the DPI setting. Sure, this may not leave you with much working space, but you'll be able to launch your apps and see if the menus and whatever else scale up properly. If you're running Windows 7 and want to see how Windows 8(.1) handles it, download the Enterprise trial and install it in VMware (or similar).

I'm surprised some people purchased the system with QHD+ display without checking this out first, but I suppose maybe not everyone realizes how much work there is yet to be done for high-DPI support on Windows (especially compared to OS X where this is pretty much all worked out already).

 

Mac OS uses a completely different approach to scaling. First, apps that actually support HiDPI must have two sets of art assets, one standard set and one "@2x" set; the latter is used when a HiDPI display is in use. But they way the Mac simulates other resolutions is also different; it leads to a nicer result but cost more resources. For example, to render its "Looks like 1920x1200" mode, it uses the @2x assets, then renders the desktop internally at 3840x2400 (double the simulated resolution in each direction, since it's using art assets twice as large), THEN uses GPU scaling post-render to shrink the composited image down to the panel's native resolution. Rendering at higher resolution and then scaling can carry a significant performance penalty, but as anyone can see, it does lead to a cleaner result -- but again, that's because the apps are required to have that set of @2x art assets. As for why even non-Retina apps seem to behave better, maybe Mac OS has a graphics engine that's more conducive to that type of per-window GPU scaling than Windows? Or maybe Windows has the technically more versatile approach overall (but as a result is less optimized for any one setup), whereas Macs can make their single implementation look perfect and don't need to worry about broad support? I guess that's the benefit of controlling both the hardware and software environments.

The Mac approach wouldn't be able to support a wide range of different PPI displays effectively, but if Apple only ever offers a "regular PPI" display and a "2x PPI" display, that shortcoming will never be exposed. Windows on the other hand is expected to run well on a much more diverse hardware ecosystem (e.g. "1.33x PPI" and "1.5x PPI"), so Microsoft can't design in a way that only allows two options like Apple.

 

Yeah, I think Windows's approach has some benefits as OS X's support is simpler (just render everything 2x with new assets, and scale the entire display up/down if 2x is not what the user wants). But the Windows approach requires more work on the part of the application developers, as getting high-DPI working isn't as simple as coming up with 2x assets. This is work a lot of people have neglected or ignored because very few people had a reason to set the DPI scaling value to anything other than 100% until high-DPI displays hit the scene rather recently. But, a lot of people don't care about the technical differences between the scaling implementations, they just expect their apps to look nice and not be tiny on the screen.

Hopefully the growing pains will work out soon as app developers realize this is something to pay attention to. I think Microsoft has more work to do as well (multi-display scaling in particular, while it works in Windows 8.1 it seems a bit like a hack to me).

 

Totally agree, and I think this will start getting attention now that HiDPI hardware has finally come over to the PC side. There's always the chicken and egg problem though; people won't buy HiDPI if it doesn't work well, and devs won't make HiDPI work well if nobody's using it. The Windows approach to per-display DPI scaling is a bit of a hack, but it's about all you can do and is actually exactly what Mac OS does. The only difference is that on the Mac, you can optimize your DPI scaling for the non-primary display, which you can't in Windows and which I would really, REALLY like to do. Regular-DPI content optimized for a regular panel looks really ugly when dragged onto the QHD+ panel and scaled up, but optimizing for the QHD+ panel and scaling DOWN for my external displays actually looks pretty reasonable -- but that requires me to use the QHD+ panel as primary, which doesn't make sense with my desk layout. On the Mac you have the option to "Optimize for Retina" or "Optimize for external display", regardless of which one you designate as primary.

Optimizing for both simultaneously would require apps to re-draw themselves with new DPI settings (and potentially new art assets) when they were dragged from one display to another -- never mind how they would handle that if the app was spanned across two displays. I just don't see that working out too well, and talk about complexity for the app developers! The Mac/Windows co-existence mode seems fine to me; Windows just needs the addition of optimizing for the non-primary.

 

I think at the very core the difference is that OS X is using a vector graphics engine (Display PostScript) meaning that internally graphics are represented in a resolution-independent format. This is something that should have happened in Windows, and had been announced to happen, many years ago, but Microsoft never actually made that investment. The latest opportunity to fix this glaring omission in Windows was Windows 8, but once again Microsoft decided to not bother taking Windows into the future. Don't even get me started on WinFS...

As a consequence, Windows' display graphics foundation cannot be described as anything other than ancient, and far, far behind the state of the art. I would go so far as to say that this stuff is nothing short of a disgrace in this time and age, and there is no excuse for this sad state of affairs. The consequence is that you guys with those HiDPI displays suffer...

 

While OS X has more vector graphics than Windows, it's not completely vector graphics, otherwise the "@2x" art assets I mentioned wouldn't be needed. 100% vector graphics just wouldn't be feasible for a whole host of reasons, not the least of which would be the much higher computational load on the CPU and GPU to draw them, which would adversely affect battery life, operating temperature, etc. Vector graphics are also just much harder to create when the graphics get complex and can result in much larger file sizes, even compared to an art asset that has multiple iterations for various resolutions/DPIs.

Windows has moved some things to vector, but they do have a ways to go on that front, and even if they get as far as they'd like to in an ideal world, they still need to provide a solution for handling raster graphics.

 

No, it doesn't. It's an antiquated remnant of days long past.

Of course, it can't be entirely vector-based, because many, many assets are naturally raster-based. This is the same as with any PDF file: If there's any images in there, then most of the times these are inserted as raster-graphics. What I was talking about was the foundation things are built on: For PDF files, and for the Display PostScript in OS X, that's a vector graphics foundation. For Windows, it's a raster graphics foundation.

Oh, and no, with modern graphics hardware vector graphics is not necessarily significantly more resource-intensive. In fact, re-scaling vector assets in hardware can be more efficient than doing the same with raster graphics.

Finally, file sizes for true vector graphics are almost always smaller, and most of the time much, much smaller than for similar raster graphics.

 

The benefit to the Windows approach I was referring to wasn't the entire platform, but rather the idea of scaling screen elements to the exact desired size based on resolution and PPI rather than having only two options (regular DPI and 2x DPI) and then using GPU scaling to bridge the gap up or down as needed after rendering internally above or below the actual resolution. There ARE benefits to that aspect of what Windows is doing (or trying to do) to handle scaling, it's just more difficult -- but supporting a broader range of hardware usually is. And unfortunately, until that difficulty is overcome, it will compare unfavorably to a platform that only has two options because it knows it will only ever NEED two options -- again, the benefits of controlling both your hardware and software ecosystems. Windows has the longer road ahead of it for supporting scaling well, but assuming it gets sorted, it will ultimately have the more flexible (or at least resource-efficient) method of doing so.

I know that vector graphics tend to be smaller than raster, but only for graphics that are "vector-friendly". For example, a vector version of a digital camera photo would be significantly larger than the original raster version, hence my point that going to purely vector graphics alone wouldn't be a reasonable option, nor would it obviate the need for a solid scaling implementation.