-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Matteo, I have attached the current state of my focus handling patches. They are more readable than the last ones and contain additional tests, but they're not finished yet. I hope they help with the gamma restore handling. I'd be interested to know if they pass for you on Windows. Especially d3d9ex has unreliable / buggy behavior on my Windows boxes. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUPtvBAAoJEN0/YqbEcdMw6JoP/jIUtgxta1SubRejbBz6lVS3 +CXS5WFNV8Kpc1fKpK6VRqs+HHNy7fH55zXAuw3KCzIarh7JPPjrgP2U4pSzuaHa fH2cWhysMbxK2tKRD0VHiZY696H/rpGgqFVwxusQuB/+Pzeqe7wpSOFOJ2QGUWqb GuAm4YFRfNdXaSQ94c4NBMU+a4N+TcXuI7YDus3WDcDIASAUnMs3i3NCmh/0IxI0 wrIfuY1szbVqI+qs6eGeN0TzTcRgEC9QHrevwdOyE7OsiN7z850wKX0k/zHxuHCl BazHk6JS0i0r3r9V+6NmUVCAqmplY93Kr04hHWxJDMWIilIxvVHs62m+wEBg+pDC LBTVlJhh28fPNAM6pPqrTUeAKnNGXwd+bevGrjl1035+qokKsj2VbIL6TnP2vDKo APORCXZ7INPp8c4EVIKHex60N2+Ec+Y8CWruUtn/UIJeMue2dgKxEq/FY5c4otWn Xu2OIUe/76cWG1tNxsTp6QhauYCW/JlteBKkyNnt/Wj/1I2LkQ8PxKEwNNCF9sbq +0oQIbLH0TRO5qU4uNAiKzPhFY4Sgy6RfMZpNpyQLSm0rT7bXeIb/EnF0Isklkaz t++UztQ/1A5ZjfeH235sPuyJ61YUTFgLfFG5swZcyZTdtTa0gymG4Ku9G1P018TU gwUbjaw/QqYKJsmEcjFK =Y/QI -----END PGP SIGNATURE-----
2014-10-15 22:40 GMT+02:00 Stefan Dösinger <stefandoesinger(a)gmail.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Matteo,
I have attached the current state of my focus handling patches. They are more readable than the last ones and contain additional tests, but they're not finished yet. I hope they help with the gamma restore handling.
I'd be interested to know if they pass for you on Windows. Especially d3d9ex has unreliable / buggy behavior on my Windows boxes.
The tests pass consistently for me on my Nvidia Win 7 box. 20% of the times or so the display dies after a test run and needs to be power cycled to recover, presumably because of all the mode switching. I blame it on the display, the GPU or both. 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? For whoever might be interested in the "gamma restore handling" thing I'm working on: it's an issue somewhat related to this one, where gamma ramps set via IDirect3DDevice9_SetGammaRamp should apply only as long as the device window is fullscreen. Switching to a different window should restore the "default" gamma settings while Wine currently doesn't care about it. Except it's more convoluted than that, setting or getting gamma via gdi32 shouldn't affect (nor be affected by) the d3d9 gamma settings but wined3d uses gdi32 to set the gamma. I'm still not sure how to fix it right... Cheers, Matteo
Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJUPtvBAAoJEN0/YqbEcdMw6JoP/jIUtgxta1SubRejbBz6lVS3 +CXS5WFNV8Kpc1fKpK6VRqs+HHNy7fH55zXAuw3KCzIarh7JPPjrgP2U4pSzuaHa fH2cWhysMbxK2tKRD0VHiZY696H/rpGgqFVwxusQuB/+Pzeqe7wpSOFOJ2QGUWqb GuAm4YFRfNdXaSQ94c4NBMU+a4N+TcXuI7YDus3WDcDIASAUnMs3i3NCmh/0IxI0 wrIfuY1szbVqI+qs6eGeN0TzTcRgEC9QHrevwdOyE7OsiN7z850wKX0k/zHxuHCl BazHk6JS0i0r3r9V+6NmUVCAqmplY93Kr04hHWxJDMWIilIxvVHs62m+wEBg+pDC LBTVlJhh28fPNAM6pPqrTUeAKnNGXwd+bevGrjl1035+qokKsj2VbIL6TnP2vDKo APORCXZ7INPp8c4EVIKHex60N2+Ec+Y8CWruUtn/UIJeMue2dgKxEq/FY5c4otWn Xu2OIUe/76cWG1tNxsTp6QhauYCW/JlteBKkyNnt/Wj/1I2LkQ8PxKEwNNCF9sbq +0oQIbLH0TRO5qU4uNAiKzPhFY4Sgy6RfMZpNpyQLSm0rT7bXeIb/EnF0Isklkaz t++UztQ/1A5ZjfeH235sPuyJ61YUTFgLfFG5swZcyZTdtTa0gymG4Ku9G1P018TU gwUbjaw/QqYKJsmEcjFK =Y/QI -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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/ iQIcBAEBAgAGBQJUP6xEAAoJEN0/YqbEcdMwi/QP/3+vkDQxZQGg4xooDclA7ELr 5Gp+MmmoKkc1AkZWa+KyP9JpPw15CZUtzZgusj3icneV3Vq1u6e53bLvyQtHmWAT GXylkzE1eQf0abPu3Lfd/VoA+sO/Q24SOjt9bQzhNp2Z/Sf/pm4fIplLD94lvAUB 5NJRFVfn0ISkM7eGi6tltyQEjC9sLZWLNKMxwZmWz9UDcAhhnASWNonwsYPmL35m L0NOBKq+VZ+sv7CLogCEUlruLzsSL3WYnuAuPtD4wIdDxAVgg56Cqx9Qzz2L1YJU VLMiIkAP7Kn0WsOq1PfM/bYY1B1wQMw44GShhvjeD+h0FrYlOpFv30j/RhmHw5yP dEsTsAoozbpjhZ5wjGW1Yon468KPnxWFh9C8lLkFntGftKZUJlKI81vI9LCIu4Oi euUuH9uLG/E8S5sPwnN8gkPDyNs3fBXLA4uG/hH9flqyQeIiLIIt9eq7oPXyK+bP UAEt1v4XM3EYoJWrl9DgXfgiAGlhtYn9g7ZsbxQ/oyArjaH4EiJ+5XdJqueYH4+x Wy1u+W+NvArWUzTBdJdQppfly6RDAoqfK4ppRDP0GK7wjObgFHzMec0tJCX9O95Y VQiakOe1jXs3nRKA7yBsMDRocSfHsDhkfdGiRk3wbqlVW78S09iSdK+MN3HZAEoc FBwm3Q9wzB6tTXRbe1mp =cO7l -----END PGP SIGNATURE-----
-----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-----
On 16 October 2014 13:34, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
-----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.
Probably, but it's probably also worth keeping in mind that for most applications the focus and device windows are going to be the same window, or at least have the focus window be the parent of any device windows. We're testing these separately to distinguish between them, but it's quite possible that some of the more broken behaviour is never an issue for any real applications where the device and focus windows are the same window.
participants (3)
-
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger