We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1897 - CPU spike on Windows with WM_EVENT and OpenGL
Summary: CPU spike on Windows with WM_EVENT and OpenGL
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.0
Hardware: All Windows (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-07 01:41 UTC by buckyballreaction
Modified: 2013-06-07 03:08 UTC (History)
0 users

See Also:


Attachments
Force ValidateRect to validate with OpenGL (676 bytes, patch)
2013-06-07 01:41 UTC, buckyballreaction
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description buckyballreaction 2013-06-07 01:41:43 UTC
Created attachment 1179 [details]
Force ValidateRect to validate with OpenGL

On some Windows systems, when switching from fullscreen to windowed mode in my game, the CPU will spike and the application never shows the window again.

See the part of the e-mail thread here:

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-June/088626.html

I change the window by calling:

SDL_SetWindowFullscreen(gScreenInfo.sdlWindow, SDL_FALSE);
SDL_SetWindowSize(gScreenInfo.sdlWindow, sdlWindowWidth, sdlWindowHeight);

which you can see in our source:

https://code.google.com/p/bitfighter/source/browse/zap/VideoSystem.cpp#377

Then all of a sudden the application gets stuck in WIN_PumpEvents() in SDL_windowsevents.c.  I turned on WMMSG_DEBUG and found that there was an endless stream of WM_EVENT messages.  I also found that where WM_PAINT is being handled in the callback WIN_WindowProc(), ValidateRect is somehow not clearing, or it is persisting, the WM_EVENT message like it's supposed to (according to the docs).

This may be a hardware issue.  The issue has appeared on three different systems, one of them sporadically:
 - Windows XP SP3 running in VMware 9.0 (without VMWare 3D acceleration, but with the tools and drivers installed), Host: openSUSE 12.3 x86_64, NVidia NVS 3100M 
 - Windows XP SP3 64bit running in VirtualBox, Host: Debian Wheezy (stable), Mobility Radeon HD 4100 (this was the sporadic one)
 - Windows 7 64 bit, Radeon 6770


After some tinkering, and noticing that SDL 1.2 has an exception for OpenGL in the WM_PAINT callback handler, I came up with the attached patch.

It works!  But I still don't understand the actual cause.
Comment 1 buckyballreaction 2013-06-07 01:46:35 UTC
I'm sorry that I've tried for several hours to get a consistent test-case, but I have been unable to do so.  It could be that something in our code is exacerbating some obscure issue, but I cannot find anything.
Comment 2 Sam Lantinga 2013-06-07 02:20:45 UTC
Crazy, but it should be fixed now.
http://hg.libsdl.org/SDL/rev/737cc5bad795

Thanks!
Comment 3 buckyballreaction 2013-06-07 02:23:24 UTC
Thank you!

I am curious, will this not affect other video systems other than OpenGL?
Comment 4 Sam Lantinga 2013-06-07 03:08:10 UTC
I don't think so, it should be fine.