This page addresses how scaling works (and what your options are) when working with multi-display setups that include a mixture of HiDPI panels (e.g. the QHD+ panel on the XPS 15 or an external 4K panel) and standard DPI panels (e.g. 24" 1920x1080 panels or 30" 2560x1440 panels). The issue of some applications not looking correct when scaling for a HiDPI panel is enabled (and the HiDPI panel is being used on its own) is a separate topic not addressed on this page. The bottom line for that issue is that application vendors must update their applications to handle scaling better.
If you have the XPS 15 model with the QHD+ panel and a non-4K external panel (or the model with the FHD panel and an external 4K panel) and you wish to use your built-in and external panels simultaneously, the two displays will require very different scale factors in order to work properly because the two panels have very different DPIs. Windows 8.1 allows for per-display scaling (sort of, discussed further in Technical Details) in order to accommodate simultaneous use of two displays with very different DPIs. It is enabled by default, but the setting is found by right-clicking your desktop background, selecting "Screen Resolution", selecting "Make text and other items larger or smaller" and unchecking "Let me choose one scaling level for all my displays." From there, you can use the slider to adjust the size of text and other display elements, which will affect both displays. By comparison, Windows 8.0 and Windows 7 (and Windows 8.1 if you select to use a single scale factor for all displays) only allow you to specify a single DPI scale factor applied to all displays, which does not work as well when using standard DPI and HiDPI displays simultaneously because there is no single scale factor that will work reasonably well on both types of displays. Note that whenever making any changes to scaling modes or scale factors in this interface, or whenever the scale factor changes as a result of connecting or disconnecting an external display or changing the display designated as primary, you will need to log off and back on to see the full effect of the change. This is because although Windows 8.1 has a new "WM_DPICHANGED" message to notify applications when the DPI scale factor has changed, this feature is so new that few applications actually support it and react to it on the fly. Those who remember using Windows 95 might recall that back then, a restart was required just to change the display resolution. That was true for the same reason: back then, applications didn't support the (then-new) message from Windows that notified them of a resolution change and thus didn't react to the change. Eventually application support for this notification became commonplace, and consequently a restart for a resolution change is no longer required. That may also happen with DPI scale factor change notifications as well, but it's simply too early at this point.
Unfortunately, even Windows 8.1 per-display scaling does not deliver multiple, truly independent DPI scale factors on different displays. Instead, Windows chooses the best DPI scale factor for the display you have designated as primary (adjusted based on your selection on the sizing slider), and then it performs post-render resizing of display elements on the non-primary display(s) so that elements on those displays appear at approximately the same physical size as your primary display. Windows does not actually redraw the elements at a different DPI scale factor on those displays. What does this mean and what is the impact?
Let's say you had the QHD+ panel in your system and also had an external 24" 1920x1200 display, and you wanted to use the latter display as primary. Windows behind the scenes would select a DPI scale factor appropriate for that display, i.e. 100% unless you moved the sizing slider closer to Larger. This means elements on the external panel will look perfect, but of course using 100% scaling on the QHD+ panel would result in tiny display elements, so instead, elements on the QHD+ panel when per-display scaling is enabled will essentially be enlarged, similar to blowing up a digital photo. As you may expect, taking a display element that was internally rendered at 100% and blowing it up to approximately 200% (as opposed to actually re-rendering for 200%) does not look great. It's much better than the alternative of unreadable text and microscopic images, but nowhere near as good as rendering display elements at 200% in the first place. More on why this isn't done in the next section.
Now let's consider the opposite scenario: You have the same built-in QHD+ panel and external 24" 1920x1200 panel, but this time you wish to use the built-in panel as primary. In this case, Windows will use a 200% scale factor as a baseline (appropriate for a 15" QHD+ panel), and elements on the external display will be scaled DOWN so they don't appear massive on your external panel, similar to shrinking a digital photo. Taking an element rendered at a higher DPI scale factor and shrinking it down actually looks pretty good, especially compared to the opposite process described above -- but even this setup means that elements on the external panel won't look as good as they would if the external panel were set to primary so that elements were actually optimized for it in the first place.
The bottom line is that, currently, when you mix displays with such radically different DPIs, only one display can ever look its best at a time. This incidentally is exactly what Apple does with notebooks equipped with Retina displays. In this same hardware setup of an internal Retina display and "standard" external display, Mac OS X allows the user to "Optimize for Retina" or "Optimize for external display" and performs this same digital expansion and shrinking depending on what you select, with the result that only one display will ever look its best. The one improvement on the Apple side is that you can choose to optimize for a non-primary display, which can be handy if for example you're giving a presentation and want elements to look best on the secondary display (e.g. a projector) while keeping your built-in panel as primary to keep desktop icons, your taskbar, and other elements there instead. Windows 8.1 does not currently allow this.
What are my optimization options now?Edit
Other than using the existing functionality described above, there are only two other options.
One is of course not to use standard DPI and HiDPI displays simultaneously. That way you can always use a single scale factor appropriate for the display(s) you're using, and therefore display elements will always be optimized for your current setup, without any of this per-display scaling going on. The drawback of course is that you can't use all of your available displays, and when you switch between normal DPI and HiDPI work, you'll need to log off and back on for the scale factor to change.
The other option is to run HiDPI panels at a standard resolution whenever you're also working with other standard DPI panels, e.g. running the built-in QHD+ panel at 1600x900 rather than its native 3200x1800. That actually looks pretty good since 1600x900 is exactly half the horizontal and half the vertical resolution, so you should have little to no scaling blurriness normally associated with running LCD displays at non-native resolutions. In fact even running 1920x1080 on the QHD+ panel looks better than you might expect simply because the pixel density is so high that any blurriness becomes much more difficult to perceive. Just like the previous option, this would allow you to use a single scale factor appropriate for all displays in your current configuration, but of course you give up the benefit of HiDPI during those times. And if you switch your HiDPI panel back to its native resolution when you're not also using a standard DPI display, you'll also need to adjust your scale factor to be appropriate to the higher resolution, which means you'll also need to log off and back on.
Why isn't there a better solution?Edit
So why can't Windows and Mac OS X optimize for both types of displays simultaneously? Well, that would require them to draw display elements differently pre-render based on the target display, rather than rendering everything identically and performing any necessary scaling post-render as they do now. The trouble is that some applications use different art elements depending on the scale factor being used. For example, iOS and Mac OS X applications optimized for Retina displays must include regular-size art for use with standard displays and "@2x" art for use with Retina displays. The reason is that, as discussed above, simply starting with higher-resolution art and scaling it down for standard-resolution applications yields an inferior result compared to using art actually optimized for standard-resolution displays. An extreme example of this is the "favicon" used on websites. Any Web designer will attest that if you simply start with a high-resolution logo and use scaling to shrink it down to the 16x16 pixel size required for a favicon, the result will be anywhere from subpar to terrible and unrecognizable. So instead, those logos are almost always manually redrawn specifically for that output size in order to look reasonable and resemble the original. Broader usage of vector art would mitigate this problem somewhat since it can scale to different sizes more easily by design, but vector art isn't an ideal option in all cases for UI elements, so a solution for raster art would still need to be provided -- and in fact even vector art is occasionally adjusted depending on the intended rendering size. Fonts, for example, are vector-based, but many fonts include multiple variants of their typeface characters for different size ranges because sometimes there is no single typeface model that yields ideal output for all sizes ranging from very small to very large.
Now, some applications already include multiple sets of art assets so they can look good both on standard DPI and HiDPI displays (when used separately from each other), so the availability of art isn't as much of an issue. And in fact the new "WM_DPICHANGED" message introduced for Windows 8.1 notifies applications when the majority of their window has been dragged from a display of a certain DPI to a display of a very different DPI so that they can react to that event if they are coded to do so. But supporting that would not only require application vendors to provide multiple sets of art assets, but also to ensure that the application could dynamically redraw itself using different art assets without creating bizarre graphics issues in their UIs. Additional challenging scenarios would be applications that had different instances open on both types of displays (e.g. the same browser with different windows open on each type of display), which would require simultaneous use of different art assets and thus increased resource consumption, or a single application window spanned across multiple displays, which would require simultaneous use of different art assets within the same application window, increasing the potential for graphics issues. This multi-DPI solution would therefore be more resource-intensive to run and would require far more work to implement properly compared to the multi-display scaling strategy implemented today.
Will there ever be a better solution?Edit
So will we ever get real multi-DPI support? This author doubts it. Application vendors would have to commit resources to implement and test support for dynamic rescaling, which may prove to be a significant undertaking. The trouble is that they may not bother because this whole problem is temporary anyway. HiDPI displays are only going to become more commonplace -- smartphones have had them for some time, Apple has built notebooks with them for a while, they're starting to show up in PC notebooks, and 4K desktop displays have started to become available. Therefore it won't be long before people with a HiDPI display somewhere have HiDPI displays everywhere, never a mix of standard DPI and HiDPI. At that point, it will once again be possible to use a single scale factor, with no need for any of the current post-render resizing or support for dynamic rescaling. Of course application vendors will still need to ensure that their applications handle general scaling in order to be usable in this "HiDPI-everywhere" era, but that's much less work than supporting dynamic rescaling and is also a much more justifiable investment of resources since HiDPI displays are here to stay, whereas coexistence with standard DPI panels is a problem that will disappear.