Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clock example doesn't resize smoothly #551

Closed
raphlinus opened this issue Feb 16, 2021 · 3 comments
Closed

Clock example doesn't resize smoothly #551

raphlinus opened this issue Feb 16, 2021 · 3 comments
Labels
question Further information is requested

Comments

@raphlinus
Copy link

When resizing the clock example, there are two sets of artifacts. One is that the surface is transitorily scaled to the window size. The other is that there are thin (usually black) strips that poke through on the right and bottom edge.

Now this is a topic I've explored deeply. I wrote a blog post on the issue, and touched on it briefly in the followup: the compositor is evil. I believe this is a design flaw in Windows rather than a problem with the Rust bindings specifically. But I am raising it here because sample code carries considerable authority in communicating to people the "right way" to do things, and, aside from this issue, the code shows considerable sophistication in using Direct2D correctly (it's almost as if the authors have some experience creating pedagogical materials).

There is a very simple fix: remove FLIP_ from the DXGI swap effect. The older DX11 swapchain presentation modes contain synchronization between the presentation of the swapchain surface and display of window chrome for the resize. In particular, based on experimentation I believe it delays the latter until the point at which the former has landed. The newer DX12 modes are higher performance and are obviously recommended for games, in which resizing the window is rare and not really expected to work, but loses the internal synchronization on window resize. This is somewhat of an agonizing dilemma, as I'd certainly like to be able to use the capabilities and performance of DX12 in desktop apps.

Also note: the black strips can be solved by setting WS_EX_NOREDIRECTIONBITMAP on the extended window style. But that doesn't solve the scaling artifacts, and also degrades the ability of the window to accept menus. Another minor point is that the constant has type i32, but the CreateWindowExA function expects u32 (= DWORD). That seems to derive from SystemServices.manual.cs, and looks inconsistent to my eyes: the WS_ window style constants are uint while the WS_EX_ constants are int. I'll note winapi-rs doesn't have this problem, all such constants have DWORD type.

Probably the best resolution of this bug is to consider resizing artifacts to be part of the visual branding of "modern" Windows 10 development, a charming reminder of the unmanageable complexity of the operating system stack of today. But it's nice to dream that it could actually be fixed.

@kennykerr
Copy link
Collaborator

I originally wrote the Clock sample in C++ for my Pluralsight courses on Direct2D and friends. https://kennykerr.ca/courses/

At the time, the flip presentation model was required for store apps. The original Clock sample ran on Windows Phone as well as desktop and store apps. It probably doesn't matter anymore, but that's the motivation for this code. And yes, that's more a question for the Windows APIs themselves but I do agree that good samples go a long way. Thanks for the feedback! Feel free to contribute an improvement to the sample.

I also created an issue with the metadata repo about the incorrect use of signed types. microsoft/win32metadata#140

@kennykerr kennykerr added the question Further information is requested label Feb 16, 2021
@knopp
Copy link

knopp commented Feb 17, 2021

I noticed that signed constants go way beyond messages and window flags. Those back and forth casts do make using the bindings bit cumbersome. Fingers crossed this gets fixed soon.

@kennykerr
Copy link
Collaborator

Yes, Steve is working on these but if you find more please report them here: https://github.com/microsoft/win32metadata

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants