Lagging to show on taskbar (Windows 7)

[Cuban-Pete]

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]

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]

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.

[werker]

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]

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]

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]

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!

[l0ud]

I have the same problem since I can remember

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

[Cuban-Pete]

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]

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

[poeboy]

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.