On 2020-07-02 17:54, Gabriel Ivăncescu wrote:
On 02/07/2020 18:16, Rémi Bernon wrote:
On 2020-07-02 17:14, Gabriel Ivăncescu wrote:
Hi Rémi,
On 02/07/2020 16:14, Rémi Bernon wrote:
Hi,
I investigated this logic a while ago, and I believe it's a little bit more convoluted. I think there's, for instance, some interaction with the WINED3DCREATE_NOWINDOWCHANGES flag, but the behavior also varies between ddraw, d3d <= 9, d3d >= 9ex and dxgi.
AFAICS there's also the same kind of change / restore logic with window visibility, and of course window styles -- which wined3d incorrectly modifies.
I have some patches with some more tests showing that, but it was based on some other changes to remove the window styles updates, that I sent a while ago but didn't try sending again since then.
I'm attaching my whole series if you want to have a look, potentially the additional tests can be interesting. Feel free to take over it too.
Thanks for the patches, I'll take a look at them. Though I think WS_EX_TOPMOST deserves special handling, because it can't be modified with SetWindowLong like other styles.
Sure, there's also window visibility that may be changed or restored in the same way (not sure if it can be controlled through styles).
BTW, I can't find where WINED3DCREATE_NOWINDOWCHANGES is set at all. It's checked in a couple of places but not set anywhere in whole wine tree. Is it even used anymore?
It's not used directly IIRC but it has the same value as some corresponding D3D flag.
I've had a quick glance at your patches, since they seem very thorough, and while they add a lot of new flags, I couldn't find a way to trim most of them down because of the various behavior between ddraw/d3d9/dxgi.
The only thing is WINED3D_SWAPCHAIN_RESTORE_WINDOW_STATE. This flag seems redundant, because you can flip the meaning of the NO_ZORDER and NO_VISIBILITY flags instead. For example, in DXGI you use NO_VISIBILITY_CHANGES and RESTORE_WINDOW_STATE, so you could just use the RESTORE_ZORDER flag. And where you set the NO_*_CHANGES flags you just clear the RESTORE_* flags instead. Unless I am missing something?
But, was there a specific blocker in particular? I feel like if I add the special case for dxgi with the WINED3D_SWAPCHAIN_RESTORE_WINDOW_RECT rename as Henri suggested, it will complicate the logic in your patches since the state restore thing seems to also apply to d3d9 if extended.
Or was there another reason?
Thanks, Gabriel
To be honest it's been a while and I'm not sure anymore why all of these were required. I simply remember that the tests showed the individual aspects (z-order, visibility, style), and that it was dependent on the API used.
I'm not even sure if it's entirely correct either, it looks like the testbot run from earlier indicated some mistakes in extended style for instance. I think the tests are though, and the few errors in the test run seem unrelated and pre-existing.