Re: [PATCH 8/9] wined3d: Filter messages generated by focus handling.
On 4 December 2014 at 21:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
We may want to consider moving mode changes, window setup and focus loss handling into the client libs. With this patch and the next one we have 3 wined3d flags just for focus loss handling. Furthermore, dxgi yet again has different behavior - it doesn't hook the window procedure and Yeah, possibly, although I'd also like to keep the amount of Win32 specific stuff in the public wined3d API to a minimum, so I'd rather not have the client libs e.g. handle window messages directly.
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index ae6600e..89ec00a 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -4961,7 +4961,7 @@ void device_invalidate_state(const struct wined3d_device *device, DWORD state) LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL unicode, UINT message, WPARAM wparam, LPARAM lparam, WNDPROC proc) { - if (device->filter_messages) + if (device->filter_messages && message != WM_DISPLAYCHANGE) That seems pretty specific. I'd be curious how other broadcast messages are handled.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2014-12-08 um 12:04 schrieb Henri Verbeet:
- if (device->filter_messages) + if (device->filter_messages && message != WM_DISPLAYCHANGE) That seems pretty specific. I'd be curious how other broadcast messages are handled. I did some testing on this and tried to send some messages to the window from inside the WM_DISPLAYCHANGE message handler. I did not manage to get any message through, not even WM_DISPLAYCHANGE. HWND_BROADCAST doesn't help either. Broadcast messages are sent to other windows (e.g. the device window) as expected.
It is possible that WM_DISPLAYCHANGE and WM_IME_NOTIFY are generated by d3d9 rather than just whitelisted. The behavior is also different if the device is created by a thread that does not own the window. In this case the owning thread has to pump messages, otherwise CreateDevice gets stuck. A lot more messages can be seen, but not WM_WINDOWPOSCHANGING / WM_WINDOWPOSCHANGED. I don't plan to spend more time on the filtering behavior until we find an application that has trouble with the current code though. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUvPy+AAoJEN0/YqbEcdMwnfUQAILuR3RdaNvJ0DZIB5b3ifgm o/dhCRM9za3+y/TVm0k/nQBtYduVsAFk4vFvvOjE0gc+pddVhcFE+FFPv/BaXSLN jGhyJyOiDMn+4ETzDLw4AzpAkx0eVZfAJSbonDgWLLHCyYbolPjg8V3G/62Vaj85 GSEG5icXxAIRRZgjyDaqdEEI3u/oYsdBtl8EssmhJ0t8qr7vjyfgCrn7MuWngnxu CB2+qDTWU3zxoam03VFM+W3fKWtmHOhI/S1kknepBtv50X4ny/ZwqmbgFQDL4pIw Ejlh9AH/cGkrwWTGOEYr8M2ZSNSM4IRmCCFz4GUkZOhJ3tnn1lCOKdn4P1x8CSFy oqELJQmE0shrBLUVWE3sgldjqYUFhCjPbBM0gVF8J9t1VQQVd8+txqirJx5ki6Kr I8ZEspoCOPdw5ojj9HuI7slJh3xP1jD7YtrfjAwEdINwblSAhHanBRItFg+jSO5I mS6c89WKLzD6qr8ibgazhWIgCdHIyJjLvCTWonQQrUAjGVdUM/NQMzzkpBpxt7IP V4qqeypZ9072tK90s8gP/s0Uq9FR3pUYKEWsS9Fu2+7EZAGSvCEGdldjMvDWh2gd P9NbXooR3BoR/eTEXysT63jy/YeBPDJNpkK7T20qIbRmt/vUYipkA8QvPs478TLy XsrUtSA3DN2OqHBNENVI =LK+0 -----END PGP SIGNATURE-----
On 19 January 2015 at 13:46, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am 2014-12-08 um 12:04 schrieb Henri Verbeet:
- if (device->filter_messages) + if (device->filter_messages && message != WM_DISPLAYCHANGE) That seems pretty specific. I'd be curious how other broadcast messages are handled. I did some testing on this and tried to send some messages to the window from inside the WM_DISPLAYCHANGE message handler. I did not manage to get any message through, not even WM_DISPLAYCHANGE. HWND_BROADCAST doesn't help either. Broadcast messages are sent to other windows (e.g. the device window) as expected.
Perhaps more concretely, if for example the time is changed (e.g. because of an application calling SetSystemTime() or DST adjustments), do you receive WM_TIMECHANGE, or is it filtered?
participants (2)
-
Henri Verbeet -
Stefan Dösinger