On 4 December 2014 at 21:51, Stefan Dösinger stefan@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
On 19 January 2015 at 13:46, Stefan Dösinger stefandoesinger@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?
-
Henri Verbeet -
Stefan Dösinger