New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix "tray lags" and language selector disappearance on windows #328

Closed
ZLOFENIX opened this Issue Dec 14, 2012 · 13 comments

Comments

Projects
None yet
5 participants
@ZLOFENIX

ZLOFENIX commented Dec 14, 2012

SFML-master\src\SFML\Window\Win32\WindowImplWin32.cpp
Line 207: while (PeekMessage(&message, m_handle, 0, 0, PM_REMOVE))
Replace with: while (PeekMessage(&message, NULL, 0, 0, PM_REMOVE))
This will remove "tray lags" and language selector disappearance on windows.
Just spent all day to discover it.
YAY !

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 15, 2012

Member

I think it was already discussed before (did you check the forum?). The thing is, I don't know why it fixes these problems, and I don't know if it has side-effects. I'm not supposed to call this function with a NULL handle.

Member

LaurentGomila commented Dec 15, 2012

I think it was already discussed before (did you check the forum?). The thing is, I don't know why it fixes these problems, and I don't know if it has side-effects. I'm not supposed to call this function with a NULL handle.

@ZLOFENIX

This comment has been minimized.

Show comment
Hide comment
@ZLOFENIX

ZLOFENIX Dec 15, 2012

I didn't find it on forum.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644943(v=vs.85).aspx
Therefore if hWnd is NULL, both window messages and thread messages are processed.

Why there must be side-effects ?
You know how to fix, but you wont - why ?

ZLOFENIX commented Dec 15, 2012

I didn't find it on forum.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644943(v=vs.85).aspx
Therefore if hWnd is NULL, both window messages and thread messages are processed.

Why there must be side-effects ?
You know how to fix, but you wont - why ?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 15, 2012

Member

Therefore if hWnd is NULL, both window messages and thread messages are processed.

If I process messages from other windows, and remove them from the message queue, there will obviously be a problem ;)

Why there must be side-effects ?

See above.

You know how to fix, but you wont - why ?

I didn't say that I wouldn't fix it, but this is not a clean solution. Before applying a patch I need to understand why it solves the problem (and nobody knows, right?) and what bad side-effects it can have (see above).

Member

LaurentGomila commented Dec 15, 2012

Therefore if hWnd is NULL, both window messages and thread messages are processed.

If I process messages from other windows, and remove them from the message queue, there will obviously be a problem ;)

Why there must be side-effects ?

See above.

You know how to fix, but you wont - why ?

I didn't say that I wouldn't fix it, but this is not a clean solution. Before applying a patch I need to understand why it solves the problem (and nobody knows, right?) and what bad side-effects it can have (see above).

@ZLOFENIX

This comment has been minimized.

Show comment
Hide comment
@ZLOFENIX

ZLOFENIX Dec 15, 2012

You do it wrong.
If not null - messages will be from window.
If null - messages will be from window and from thread.
IMHO not null will not process thread messages and this cause bugs.
IMHO2 you will not get messages from other windows in system, only from your window(s).

ZLOFENIX commented Dec 15, 2012

You do it wrong.
If not null - messages will be from window.
If null - messages will be from window and from thread.
IMHO not null will not process thread messages and this cause bugs.
IMHO2 you will not get messages from other windows in system, only from your window(s).

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 15, 2012

Member

IMHO not null will not process thread messages and this cause bugs.

This is possible, so this should be investigated further.

IMHO2 you will not get messages from other windows in system, only from your window(s).

The MSDN says that:
If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread

So, if the program creates both a SFML window and a Qt (for example) window in its main thread, this call will process and remove messages for both windows. This is clearly a problem.

Member

LaurentGomila commented Dec 15, 2012

IMHO not null will not process thread messages and this cause bugs.

This is possible, so this should be investigated further.

IMHO2 you will not get messages from other windows in system, only from your window(s).

The MSDN says that:
If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread

So, if the program creates both a SFML window and a Qt (for example) window in its main thread, this call will process and remove messages for both windows. This is clearly a problem.

@ZLOFENIX

This comment has been minimized.

Show comment
Hide comment
@ZLOFENIX

ZLOFENIX Dec 15, 2012

Ok, i have workaround: add define/var for which PeekMessage use and add it to documentation, so who use sfml to create window will just define var and have no problems.

ZLOFENIX commented Dec 15, 2012

Ok, i have workaround: add define/var for which PeekMessage use and add it to documentation, so who use sfml to create window will just define var and have no problems.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 15, 2012

Member

This is ugly.

I'm sure there is a clean solution; and finding this solution probably requires to investigate the problem deeper (ie. what are "thread events", why does passing NULL to PeekMessage have an effect on this particular bug, etc).

Just because it works for you doesn't mean that this is the ultimate solution and that I should rush to change the code. You've found a solution, great, now you should try to understand it ;)

Member

LaurentGomila commented Dec 15, 2012

This is ugly.

I'm sure there is a clean solution; and finding this solution probably requires to investigate the problem deeper (ie. what are "thread events", why does passing NULL to PeekMessage have an effect on this particular bug, etc).

Just because it works for you doesn't mean that this is the ultimate solution and that I should rush to change the code. You've found a solution, great, now you should try to understand it ;)

@retep998

This comment has been minimized.

Show comment
Hide comment
@retep998

retep998 Dec 16, 2012

When a window does not have its events handled, it becomes unresponsive. Likewise, I assume there must be some sort of window being created for the taskbar or whatever which has events which are not being handled. By passing a NULL, you receive all events on that thread, including taskbar events, thus eliminating the unresponsiveness. Unfortunately, this also obtains events for other windows, such as a Qt window. Thus, what we need to do is determine the hwnd of the task bar thingy and specifically handle its events as well.

retep998 commented Dec 16, 2012

When a window does not have its events handled, it becomes unresponsive. Likewise, I assume there must be some sort of window being created for the taskbar or whatever which has events which are not being handled. By passing a NULL, you receive all events on that thread, including taskbar events, thus eliminating the unresponsiveness. Unfortunately, this also obtains events for other windows, such as a Qt window. Thus, what we need to do is determine the hwnd of the task bar thingy and specifically handle its events as well.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 16, 2012

Member

Do you really think that the Microsoft engineers designed the Windows API this way? I don't think so. And I've never seen this in any Win32 program.

Yesterday I've investigated a bit, and found that in other popular graphics libraries/engines, PeekMessage is called with a NULL argument. So if we don't find more relevant information, we could assume that it's safe. However I've also found someone complaining about the same problem on the Ogre forum, and he got no answer. So it may not be totally safe.

Member

LaurentGomila commented Dec 16, 2012

Do you really think that the Microsoft engineers designed the Windows API this way? I don't think so. And I've never seen this in any Win32 program.

Yesterday I've investigated a bit, and found that in other popular graphics libraries/engines, PeekMessage is called with a NULL argument. So if we don't find more relevant information, we could assume that it's safe. However I've also found someone complaining about the same problem on the Ogre forum, and he got no answer. So it may not be totally safe.

@vonj

This comment has been minimized.

Show comment
Hide comment
@vonj

vonj Dec 16, 2012

Actually, based on what I read here, http://msdn.microsoft.com/en-us/library/windows/desktop/ms644943%28v=vs.85%29.aspx , I see no other way of doing it.

"If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread, and any messages on the current thread's message queue whose hwnd value is NULL (see the MSG structure). Therefore if hWnd is NULL, both window messages and thread messages are processed."

vonj commented Dec 16, 2012

Actually, based on what I read here, http://msdn.microsoft.com/en-us/library/windows/desktop/ms644943%28v=vs.85%29.aspx , I see no other way of doing it.

"If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread, and any messages on the current thread's message queue whose hwnd value is NULL (see the MSG structure). Therefore if hWnd is NULL, both window messages and thread messages are processed."

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 16, 2012

Member

And?

No other way of doing what?

Member

LaurentGomila commented Dec 16, 2012

And?

No other way of doing what?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Dec 16, 2012

Member

Actually, it could be a good idea to check which extra messages are processed when you pass a null HWND, maybe it will help to understand what's going on.

Member

LaurentGomila commented Dec 16, 2012

Actually, it could be a good idea to check which extra messages are processed when you pass a null HWND, maybe it will help to understand what's going on.

@Oberon00

This comment has been minimized.

Show comment
Hide comment
@Oberon00

Oberon00 Dec 16, 2012

Contributor

Maybe you could also try passing -1 as hWnd:

If hWnd is -1, PeekMessage retrieves only messages on the current thread's message queue whose hwnd value is NULL, that is, thread messages as posted by PostMessage (when the hWnd parameter is NULL) or PostThreadMessage.

Contributor

Oberon00 commented Dec 16, 2012

Maybe you could also try passing -1 as hWnd:

If hWnd is -1, PeekMessage retrieves only messages on the current thread's message queue whose hwnd value is NULL, that is, thread messages as posted by PostMessage (when the hWnd parameter is NULL) or PostThreadMessage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment