I created a thread on this topic a while ago and it answered some of my questions, but at this point I am facing a far more puzzling problem. The premise: A program periodically updates a window's contents by invalidating the window through a WM_TIMER loop. In normal circumstances, a 100 FPS update of the entire maximized client area generates less that 1% of CPU load. The contents are being double-buffered in a pre-allocated DC. The update is done as follows: 1) FillRect() is called for the entire client area in the back buffer 2) various stuff is drawn in the back buffer 3) the buffers are swapped (BitBlt() the back buffer into the front buffer) The problem: When some other application is run (either separately or at the same time), it may cause (this seems to happen randomly) a considerable slowdown in the blitting of the back buffer into the front buffer: the default overhead of drawing 100 FPS suddenly starts to eat up 50+ % of CPU resources, causing a general lag in all processes. The problem won't always go away if I close all other applications, but it will go away if I restart the system or switch to drawing into the front buffer directly (naturally, this means that the screen will start to flicker). The problem isn't caused by an excess of WM_PAINT messages being sent to the window (yes, I checked) - the problem seems to strictly lie with the BitBlt() function. Quite frankly I have no idea where to look or what to do about it because this doesn't seem to be a widely spread problem (it could be my system only - Windows XP). Any ideas?

First of all, GDI isn't meant for this kind of hardcore drawing. In fact, it's solve purpose isn't for games or heavy animated applications. For this, I do suggest you use DirectX or OpenGL(Or one of the many libs such as Allegro or SDL). GDI was used for drawing controls/windows and such, and it's all done in software.

I wonder, what are you drawing? How much are you drawing and more importantly, does it need to run at 100FPS? How often does it change?

You could optimize it a bit and only redraw the backbuffer when it's changed. Thus, just bitblt the bakcbuffer to the front buffer and when something has changed, redraw it, and bitblt it again.

I have no idea about your problem, or what is causing it. My best bet would be to use SDL/DirectX. Which doesn't solve it directly, but is a solution to bypass it.

Toolmaker

While I do appreciate your suggestion, I'm afraid I'm dealing with a somewhat more serious application than a game. Implementing a GUI for something like this in a 3D API this is an apprent overkill, not to mention a mismatch of concepts. As I wrote, framerate is not an issue - the CPU can handle raw graphics surprisingly well, as can Windows. I am not rendering anything fancy, so there is really no need for such a radical change.

As for updates - I have user input-triggered and automated changes on the GUI, so a controlled periodic update is the simplest solution.

However, as I wrote, there are isolated instances when something goes very wrong and I can't figure out what it is.

WM_TIMER is a very low priority message. It only gets issued when no other higher priority messages are in the queue. If you have many apps running its quite possible you will only get 20-30 timer messages per second. Also the timer has a low time granularity, ie if you ask for 20ms timer, it will sound at intervals between 20 and 50 ms.

Cheers
Chris