[PATCH] wined3d: Restore the Topmost state upon exiting fullscreen, when used from DXGI.

[Gabriel Ivăncescu]

Hi Rémi,

On 02/07/2020 19:06, Rémi Bernon wrote:
> 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.

So it appears I will need the RESTORE_WINDOW_STATE flag as separate, 
because d3d9ex uses it but it doesn't restore the rect.

I will later send most of the patches rebased, and most which are 
unmodified from yours, the others are slightly tweaked to also fix some 
small mistakes / dead code.

I haven't touched the following parts, though, so I'll leave those to 
you if you decide to pick them up again:

The NO_STYLE_CHANGES flag, which is quite invasive.
Adding the NO_VISIBILITY_CHANGES flag in dxgi. I wasn't able to test 
this, so I left it out—but it should be trivial to add.

Thanks,
Gabriel