You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
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 typei32
, but theCreateWindowExA
function expectsu32
(= DWORD). That seems to derive from SystemServices.manual.cs, and looks inconsistent to my eyes: theWS_
window style constants areuint
while theWS_EX_
constants areint
. 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.
The text was updated successfully, but these errors were encountered: