Would you mind if I added this to the OP as some context to the original article (separate take)?
sure you're welcome to, though you might want to cut it down to size a little. Perhaps use the TLDR and link to the full post?
Thanks for that explanation but when you say that there is no loss of functionality - this isn't actually true as so far FreeSync and DSR/VSR can't work with borderless window presentation in DWM. Or am I mistaken?
I'm not a driver developer so I can't speak to that entirely. Since with DirectX12 and DXGI 1.4 the swapchain backbuffers technically belong to the desktop compositor now (afaik), instead of to the application like they did in older versions, that could be the obstacle. Honestly I'm not sure how a driver would get around that, it'd require the driver downscaling the backbuffer for the compositor, yet still permit the compositor to offer the oversize backbuffer to the application for rendering. Really it would be simpler for DX12 drivers to do what the current crop of DX11 injectors do to add postFX and downsampling - intercepting the API calls at the application level rather than the driver level, creating a high-res intermediate buffer that the application thinks is the swapchain backbuffer, and downsampling that into the actual swapchain backbuffer that the compositor owns.
G-sync and freesync I'm even more ignorant about. I'd imagine the problem is that currently the app presents to the compositor at one rate, and the compositor then presents to the screen at a fixed rate (60hz). The fullscreen exclusive solution is that while the application is the only client of the compositor, the compositor will present to the screen at the same rate as the application (I think). I would imagine a windowed solution to the same problem is the same one - allow/force one client of the compositor to override the compositor's screen present rate even when the compositor has multiple client apps.
Like I said i'm not a driver guy, so take all that with a pinch of salt. My understanding from the app side of things is that the driver teams are still ensuring their drivers meet the API specs (as the AMD driver thing illustrates), before they then start trying to break from the specs too much.
I'm not a huge MS fanboy or whatever you want to call it (I prefer the ps4 to xb1), and I think the MS store is highly undesirable for consumers. However I'm failing to see why people are so outraged, and I'd argue with the article's assertion that moving DX12 win32 apps presentation mode to the newer one used by store apps is a calculated push by microsoft to get games on their store. Is it that surprising that the new graphics API uses the somewhat new presentation API? It is after all more efficient than the old one (no intermediate surfaces), which is what the whole DirectX 12 thing is about, efficiency. I'm not arguing that it's ideal, by any means, only that this change may have other explanations.