-----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
2014-10-15 22:40 GMT+02:00 Stefan Dösinger stefandoesinger@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 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.
On 16 October 2014 13:34, Stefan Dösinger stefandoesinger@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.
-
Henri Verbeet -
Matteo Bruni -
Stefan Dösinger