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

Lagging to show on taskbar (Windows 7) #69

Closed
Cuban-Pete opened this Issue Jul 3, 2011 · 10 comments

Comments

Projects
None yet
6 participants
@Cuban-Pete

Cuban-Pete commented Jul 3, 2011

On windows 7 (64bit) with ati hd4870 and intel duo core e8400 a SFML2.0 program that uses OpenGL takes 3 seconds or longer before showing up on the taskbar. This lagging is annoying because it also slows down the switching to other programs. For clarity, the programs starts quick, but showing up on the taskbar takes very long. Also when I try to recompile my program after a small change, it takes over 3 seconds before the program is not being used any more and I can recompile.

This lag happens also with the examples shader and window, but not with win32.

The lagging, for as far I tested, does not happen on Vista.

I made a small video of it: http://www.sfmluploads.org/index.php?page=view_file&file_id=31

@pdinklag

This comment has been minimized.

Show comment
Hide comment
@pdinklag

pdinklag Jul 4, 2011

ATI Radeon HD4870, Intel Core2Duo E8400, Windows 7 (32-bit) here.
I can't reproduce this problem. When I run SFML applications with OpenGL windows they start and exit like instantly. Note that I only tried the Release build.

So this might be related to Win7 64-bit or something's up with the Debug build, or it's something entirely different.

pdinklag commented Jul 4, 2011

ATI Radeon HD4870, Intel Core2Duo E8400, Windows 7 (32-bit) here.
I can't reproduce this problem. When I run SFML applications with OpenGL windows they start and exit like instantly. Note that I only tried the Release build.

So this might be related to Win7 64-bit or something's up with the Debug build, or it's something entirely different.

@Cuban-Pete

This comment has been minimized.

Show comment
Hide comment
@Cuban-Pete

Cuban-Pete Jul 5, 2011

Thanks for testing.

Yes, it starts instantly, but it shows up on the taskbar 3 seconds later slowing down the whole taskbar.

I don't use debug release. I do use static dll's.

Cuban-Pete commented Jul 5, 2011

Thanks for testing.

Yes, it starts instantly, but it shows up on the taskbar 3 seconds later slowing down the whole taskbar.

I don't use debug release. I do use static dll's.

@Cuban-Pete Cuban-Pete closed this Jul 5, 2011

@Cuban-Pete Cuban-Pete reopened this Jul 5, 2011

@werker

This comment has been minimized.

Show comment
Hide comment
@werker

werker Jul 5, 2011

I can reproduce that problem. I use the 2.0 snapshot from yesterday and SFML is compiled by mingw as static library.
The problem occurs on my Desktop PC with Windows 7 (32 bit).

EDIT:
And it looks like the taskbar is freezing everytime the window gets its focus back.
It seems that it's only my Windows 7 machines.

werker commented Jul 5, 2011

I can reproduce that problem. I use the 2.0 snapshot from yesterday and SFML is compiled by mingw as static library.
The problem occurs on my Desktop PC with Windows 7 (32 bit).

EDIT:
And it looks like the taskbar is freezing everytime the window gets its focus back.
It seems that it's only my Windows 7 machines.

@pdinklag

This comment has been minimized.

Show comment
Hide comment
@pdinklag

pdinklag Jul 5, 2011

In the taskbar it shows up instantly for me as well. OK, maybe half a second, at the very max, but that might as well be the IDE starting it up.

I also linked statically, although I am not using the latest build. The one I'm using should be about a month old.

pdinklag commented Jul 5, 2011

In the taskbar it shows up instantly for me as well. OK, maybe half a second, at the very max, but that might as well be the IDE starting it up.

I also linked statically, although I am not using the latest build. The one I'm using should be about a month old.

@werker

This comment has been minimized.

Show comment
Hide comment
@werker

werker Jul 5, 2011

I tried old sfml source code from the beginning of the year and the same problem occurs. I really can't tell where these freezes are coming from.
So here are some more information:

  • Windows 7 Pro (32 bit)
  • Radeon HD 4850 (newest driver)
  • tdm-gcc compiler pack (mingw alternative built)
  • static link of sfml

Maybe I will try to compile it with MSVC.

werker commented Jul 5, 2011

I tried old sfml source code from the beginning of the year and the same problem occurs. I really can't tell where these freezes are coming from.
So here are some more information:

  • Windows 7 Pro (32 bit)
  • Radeon HD 4850 (newest driver)
  • tdm-gcc compiler pack (mingw alternative built)
  • static link of sfml

Maybe I will try to compile it with MSVC.

@Cuban-Pete

This comment has been minimized.

Show comment
Hide comment
@Cuban-Pete

Cuban-Pete Jul 9, 2011

I do get this error when compiling (in VS2008):

LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

Or is it something completely different?

//damn i keep clicking close, sorry!

Cuban-Pete commented Jul 9, 2011

I do get this error when compiling (in VS2008):

LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

Or is it something completely different?

//damn i keep clicking close, sorry!

@Cuban-Pete Cuban-Pete closed this Jul 9, 2011

@Cuban-Pete Cuban-Pete reopened this Jul 9, 2011

@l0ud

This comment has been minimized.

Show comment
Hide comment
@l0ud

l0ud Jul 11, 2011

I have the same problem since I can remember

Windows 7 x64, HD4850, MinGW. Windows XP seems to be affected too.

l0ud commented Jul 11, 2011

I have the same problem since I can remember

Windows 7 x64, HD4850, MinGW. Windows XP seems to be affected too.

@Cuban-Pete

This comment has been minimized.

Show comment
Hide comment
@Cuban-Pete

Cuban-Pete Jul 15, 2011

On win7 I don't get an error, but on XP machines I do when I quit the sfml program. It says it did not work correct. Might this be connected to this problem? Running gDEBugger gives at exit an error: Second Chance Exception

Cuban-Pete commented Jul 15, 2011

On win7 I don't get an error, but on XP machines I do when I quit the sfml program. It says it did not work correct. Might this be connected to this problem? Running gDEBugger gives at exit an error: Second Chance Exception

@werker

This comment has been minimized.

Show comment
Hide comment
@werker

werker Jul 15, 2011

I think I got the reason of this all:

src/SFML/Window/Win32/WindowImplWin32.cpp
line 216:
while (PeekMessage(&message, myHandle, 0, 0, PM_REMOVE))

Of course sfml filters the messages with myHandle, so that you only get the messages from the target window.
I did some debug on my windows machine and it seems like there is a window message with the code 0xc042 (or 49218 decimal) which doesn't belong to the window handle. But you have to dispatch that message or you get that taskbar freeze that some people experience here.

So if I replace myHandle with NULL this particular message is dispatched and there is no taskbar freeze anymore. This is obviously no fix since it breaks the logic of handling events for multiple different windows.

I don't know where this message is coming from and why only some people got a problem with that but I'm sure it's the source of this freeze.

EDIT:
The last info I've got is the name of the the target window of this unknown message: "cicmarshalwnd"

Here is a kind of a fix in the event loop, that works on my system, please have a look and try it:
http://pastebin.com/53yJJ6DA

werker commented Jul 15, 2011

I think I got the reason of this all:

src/SFML/Window/Win32/WindowImplWin32.cpp
line 216:
while (PeekMessage(&message, myHandle, 0, 0, PM_REMOVE))

Of course sfml filters the messages with myHandle, so that you only get the messages from the target window.
I did some debug on my windows machine and it seems like there is a window message with the code 0xc042 (or 49218 decimal) which doesn't belong to the window handle. But you have to dispatch that message or you get that taskbar freeze that some people experience here.

So if I replace myHandle with NULL this particular message is dispatched and there is no taskbar freeze anymore. This is obviously no fix since it breaks the logic of handling events for multiple different windows.

I don't know where this message is coming from and why only some people got a problem with that but I'm sure it's the source of this freeze.

EDIT:
The last info I've got is the name of the the target window of this unknown message: "cicmarshalwnd"

Here is a kind of a fix in the event loop, that works on my system, please have a look and try it:
http://pastebin.com/53yJJ6DA

@ghost ghost assigned LaurentGomila Aug 11, 2011

@poeboy

This comment has been minimized.

Show comment
Hide comment
@poeboy

poeboy Dec 8, 2011

This bug is breaking other Windows applications. I know of at least one installer that calls SendMessage() with HWND_BROADCAST using a perfectly legit Windows system message that never finishes on some computers. Make this a priority fix. You can't call PeekMessage() in this fashion and expect it to actually work.

The returned 'message' structure from PeekMessage() contains a valid HWND with one exception (thread messages vs. window messages). Calling the function with NULL and then processing the message using the returned handle is the correct approach. But then you might as well do it right and call GetMessage() on Windows.

poeboy commented Dec 8, 2011

This bug is breaking other Windows applications. I know of at least one installer that calls SendMessage() with HWND_BROADCAST using a perfectly legit Windows system message that never finishes on some computers. Make this a priority fix. You can't call PeekMessage() in this fashion and expect it to actually work.

The returned 'message' structure from PeekMessage() contains a valid HWND with one exception (thread messages vs. window messages). Calling the function with NULL and then processing the message using the returned handle is the correct approach. But then you might as well do it right and call GetMessage() on Windows.

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