Improve PresentMode documentation/naming

[JeffersonMontgomery-Intel]

Add description of PresentMode to readme (e.g., this answer: https://github.com/DevTechProfile/CapFrameX/issues/114#issuecomment-626850576)

Also consider renaming PresentMode text to be more inline with API, MSDN, etc. Note that this could be a breaking change as various tools do rely on current naming. (e.g., to do for 2.0 major version release)

[Kein]

Hello, any chance the Present description can be improved as well, can we get some correlation between your own naming scheme and what https://docs.microsoft.com/en-us/windows/win32/api/dxgi/ne-dxgi-dxgi_swap_effect and https://youtu.be/E3wTajGZOsA tell us? It is really awkward trying to figure out which of the naming scheme for present model means.

[Kein]

My understanding so far: Hardware: Legacy Flip - this is classic Exclusive Fullscreen, for D3D11 and below - Composed: Copy with GPU GDI - Windowed Blt Hardware: Legacy Copy to front buffer - by the look of it, seems like Fullscreen (Blt)?

My issue with the last two, I've tested this on Unity 2019.3+, Borderless Windowed Fullscreen, with DWM on and off (respectively to the list above). According to Unity devs, for Win7 they use DXGI_SWAP_EFFECT_DISCARD. The thing that confuses me, Jesse says in his talk that FullScreen Blt only relevant when you set MaxRenderFrames to 1 and in Vsync ON but that is not the case of my tests.

It does not help that he was mostly talking about Win10 and D3D12 presentation models and I'm talking in the context of Win7.

[jenatali]

When DWM is off, all presents are either Hardware: Legacy Flip or Hardware: Legacy Copy to front buffer. Either the app takes over the entire screen and replaces the desktop surface (flip), or the app copies into (maybe a portion of) the on-screen surface.

[Kein]

Okay, so Hardware: Legacy Copy to front buffer is always bit-block copy to front buffer (as in the example with Fullscreen Blt - 2 swap buffer and one front buffer to copy to), it just either fullscreen blt or old windowed blt depending if app is in fullscreen or windowed? Or it is ALWAYS windowed (despite taking full screen size in borderless)?

[jenatali]

Correct, it's the same model that's used, regardless of whether the front buffer belongs to the app (fullscreen) or to the system (windowed).

[Kein]

Thanks. If we are to follow your old presentation and the same first 2 metrics (Number of surfaces and Number of copies), I assume there would be no difference between Fullscreen Blt or Windowed Blt in case of Hardware: Legacy Copy to front buffer - both are 1 - 1?

[jenatali]

Number of surfaces is a bit nuanced, depending on whether the application allocated the front buffer (fullscreen), or whether the app is using a pre-allocated front buffer, which can happen in both windowed and fullscreen modes.

Number of copies is 1.

[Kein]

Number of surfaces is a bit nuanced, depending on whether the application allocated the front buffer (fullscreen), or whether the app is using a pre-allocated front buffer, which can happen in both windowed and fullscreen modes.

Is there any information on this, ideally, if possible, in a similar format as your old D3D12 presentation (i.e. digestible even by brainlet)?

Either way, thank for the help, things a bit more clear now.