d3d focus patches

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh, and when you add to all this the strange WM_VISIBLE /
WM_EX_TOPMOST behavior on the *second* device creation, the
S_PRESENT_MODE_CHANGED on Reset to windowed (needs a second reset),
the fact that I have do minimize and restore the device window to
reliably convince d3d9ex that it has focus back (about 5% of the time
it works without that) and some other bugs I've seen in my experiments
I'm convinced that native d3d9ex is pretty broken.

Am 2014-10-16 13:30, schrieb Stefan Dösinger:
> Am 2014-10-16 00:46, schrieb Matteo Bruni:
>> I also tried to copy the d3d9 test from "wined3d: Set the device 
>> window size on focus window activation." to d3d9ex and it looks 
>> like it always passes for me. Was that the test you were mostly 
>> interested in?
> It fails about 50% of the time on my Vista machine (Geforce 7400). 
> Most of the time the WM_SIZE message is missing, but I've had some 
> really rare runs where the entire
> WM_DISPLAYCHANGING/WM_DISPLAYCHANGED part is missing.
> 
> The really interesting thing is the test in the last patch labeled 
> "unfinished". It's not the hidden window part that's tricky - this
> is consistent - but the fact that the test adds a second focus loss
> / focus restore cycle. I've had difficulties convincing d3d9ex that
> it has the focus back. This works now. In my past patchset I did
> not manage to convince native d3d9ex that it had lost focus the
> second time. I don't know yet if the device window hiding and
> showing fixes that.
> 
> Focus changes are reliable in d3d9ex for my test applications when
> I press alt-tab, but not when I use SetForegroundWindow. I even
> tried to set the foreground window to the window of a different
> process and back from there, but this does not help either. User
> alt-tab is reliable though. I have not seen a difference in the
> messages passed to the device and focus windows, so I suspect there
> is some back channel talk going on between d3d9, user32 and
> explorer.exe (or some other central component involved with focus
> handling). Any ideas would be welcome.
> 
> There is one difference in the messages I spotted: On reactivation 
> with SetForegroundWindow the WM_NCACTIVATE message instructs the 
> window to paint an inactive title bar. The window does receive
> focus though. I believe that this is a symptom rather than the
> cause. No d3d involvement is needed to see this behavior.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJUP61JAAoJEN0/YqbEcdMwS9gP/3RNJ9xrMkARWidfYpdo51Xd
kaS83rE2iuAGt3eH1fxDverC3JIkMGtMsYpXQBaxRoz9walDL7mNCqrzAOwqqbT4
Uqtn5RA8AdI3nQY73DpZ023WZ52iaNtqtCEnj2PwlJFTOVjEsCqrza0+2TOc09b5
HxyLBYhors7N7iGHgEo2rxWSdfFJQ7zcpFxSEJIwdyARUod8nXfUwib6JIPMLgZe
1Eck3TYcnyG78gODGfyMPRgn5I6MpUA42ZLORaVIJzL6kfWje3RlwC6s2vvqoe9w
gsldsesQGoL1YgoSQ0bdZTUOhg6Y8DYRuHYCmpZN1UmHf4tjhm1VPgz4/kBALEP3
HuR5Yt+JF6u9MPKxR6lpv/1q0kprib8bFaZ2mFelhB8ABj1EW6HRt6ufvavFv4HY
da+y39XKdZpCFHW29+28CwBZYR/EcyX+NaoN9BNFqn7/LVLwO7KOSzYXR39Or3n8
CI5npcfPlcdB9QyR+H5siuUsCeiPebM2yJUJqSS5zEaxDWBQS84GAdH+rhUtSq6n
X/BemUHWG7VTHIS8xfK1cJG2h+hI5215hvxnaWfetTkGgTpEugulIImzePR1ER9U
e4DwW09TvkkteXMCqKsMRCElVqTBqlqr3w1qTje99T/Ovpr7QXZCcbo6GyVVicsI
NhsQS1rqgWATIWV2TIjw
=PuFY
-----END PGP SIGNATURE-----