[win32] SDL app slow without focus

Hi all,

I’m writing the SDL mailing list as I’m at a loss how to fix a
strange problem in an SDL application I’ve written and hope that
someone can help me.

I received a bug report from a user who sees a big slowdown in my
app if the application loses focus. He has a Windows 98 OS with
what we think is Direct X 8. I’ve included a copy of his bug
report below. I’m not too familiar with Windows programming (a
reason I chose SDL in the first place), so if any one could help
me solve this problem/has seen similar things, I’d be most
grateful.

The application itself is a port of the portable MARS simulator
for Core War using SDL 1.2.5 and is available (with source) at:

http://www.cs.helsinki.fi/~jpihlaja/cw/pmars-sdl/

[The SDL port hasn’t been rolled back into the proper pMARS
package yet, available with documentation from
http://sourceforge.net/projects/corewar also see
http://www.koth.org for general information about Core War.]

The application, pmarsw.exe, was compiled with mingw 2.0 under
MSYS 1.0.8. The main thing it does is set up a SDL surface as a
window and lots and lots of blits of really tiny rectangles to
the window from pre-computed colour keyed SDL Surfaces. SDL
1.2.5 was compiled from sources with the Direct X development
headers and Direct X support.

From asking other users and testing myself, the problem doesn’t
appear under the following systems:

Windows 95, Direct X 8
Windows 2000, unknown Direct X
XFree 86

If there’s any more information I can provide, please don’t
hesitate to ask.

Best Regards and TIA,

Joonas Pihlaja

Below is a quote from his bug report. The program pShell he
mentions is an old DOS program that’s intended as a front-end to
pMARS. AFAIK it uses the system() call to execute pMARS and
doesn’t do any processing in between.

8<---------8<---------------8<----------------> I observed the following things:

I’m still running the pmarsw version with John
Metcalf’s optimizing program (written in gwbasic) and
with pShell/mts for benchmarking.
In both cases everything works as expected if the
pmarsw window is on top. If I open another window (it
doesn’t matter what it is) the speed of pmarsw will go
down by a factor of about 5-10. On the other hand also
the other programms slowing a bit down.
The most drastical effect I have if I let run the
optimizer and the pShell at the same time. If pShell
is on top every key action of pShell is delayed by 1-2
seconds. It doesn’t matter how the windows are
arranged, but I will check this after work again.

As long as pmarsw is that one which is 'highlighted’
everything is fine. The slowing down comes at the
point if I click on another window. It doesn’t matter
what kind of application it is. I’ll check that with
window behind, minimized etc. after work.

  • Does it matter what application you start in
    addition to
    pmarsw?

No, it doesn’t matter what kind of application is
opened.

M Joonas Pihlaja wrote

I received a bug report from a user who sees a big slowdown in my
app if the application loses focus. He has a Windows 98 OS with
what we think is Direct X 8. I’ve included a copy of his bug
report below. I’m not too familiar with Windows programming (a
reason I chose SDL in the first place), so if any one could help
me solve this problem/has seen similar things, I’d be most
grateful.

I don’t know of a sure solution, but I have seen Windows apps
behave this way in general. I use an ssh client to log into
my other linux machines, whenever I boot into Windows. Doing
a simple copy-paste of text from Windows into the remote shell
is slow even when the window is in-focus, but when there are
no events pending to process (like keyboard/mouse-movement).

So, if I have a large amount of data to paste into my shell, I
wiggle the mouse during the paste to get it to give the program
more CPU time, making the text scrolling in the terminal about
3 to 5 times faster.

Maybe there’s a way to write your program so that it doesn’t
give up as much control of the CPU to Windows, even when it is
out-of-focus, or when there are no currently pending events to
process (which allows other part of your code to run during the
event loop).

-Chris

Hi all,

Just wanted to let you know that we have finally found the cause
of the slowdown and report that it has nothing to do with SDL at
all — sorry for bothering you all with it.

It seems that calling my SDL app from a Turbo Pascal 5.5 program
doesn’t work at all, as that screws up the TP5.5 program’s delay
functions in some still-mysterious way. We are working on fixing
this by updating the TP5.5 app. (Isn’t open-source great? :slight_smile: )

Best Regards,

Joonas Pihlaja

Hi all,

Just wanted to let you know that we have finally found the cause
of the slowdown and report that it has nothing to do with SDL at
all — sorry for bothering you all with it.

It seems that calling my SDL app from a Turbo Pascal 5.5 program
doesn’t work at all, as that screws up the TP5.5 program’s delay
functions in some still-mysterious way. We are working on fixing
this by updating the TP5.5 app. (Isn’t open-source great? :slight_smile: )

Glad to hear you figured it out. :slight_smile:

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment