Windows XP speed problems

Hello

I’ve a big speed problem with my SDL programs, since I installed Windows XP.
Although they don’t do anything special, they run much too slow. They’re
just using some hardware surfaces and the video mode is
SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN in 16 bit. I don’t think my Radeon is too slow for the
graphics.

I wrote a little test program, that just sets the video mode and has a
little main loop, which does blits or fills and SDL_Flip(). I tested the speed
with SDL_GetTicks(). The strange thing is that when I only use about 5 blits,
everything is fine, ie. the blits take almost no time at all, and SDL_Flip() is
waiting about 1/60 second for sync. But when I do about 20 blits, the first
blit takes 1/60 second, the other blits and SDL_Flip() take almost no time.
When I use fills instead of blits, the same problem happens.

Can anyone explain this, or help me with the speed problem?–
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!

I could be way off here, but I’m thinking that the 1/60th of a second
sounds an awful lot like the delay for a h/w sync on the monitor. I
believe SDL_Flip waits for a refresh before swapping the surfaces.

As for the first blit taking 1/60th and the rest happening instantly
with the flip, how are you measuring this? In either case they should
all appear to take place at 1/60th a second since the flip would make
them visible.

If you’re just fprinting or cout-ing (I’m aware neither of those are
words) it might be that they get caught in a buffer when the delay takes
place for the flip making the following blits appear to take place
instantly. Try flusing the buffer each time you print your debugging
text (assuming this is how you were measuring the blits).On Wed, 2002-11-13 at 09:07, Martin Konrad wrote:

Hello

I’ve a big speed problem with my SDL programs, since I installed Windows XP.
Although they don’t do anything special, they run much too slow. They’re
just using some hardware surfaces and the video mode is
SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN in 16 bit. I don’t think my Radeon is too slow for the
graphics.

I wrote a little test program, that just sets the video mode and has a
little main loop, which does blits or fills and SDL_Flip(). I tested the speed
with SDL_GetTicks(). The strange thing is that when I only use about 5 blits,
everything is fine, ie. the blits take almost no time at all, and SDL_Flip() is
waiting about 1/60 second for sync. But when I do about 20 blits, the first
blit takes 1/60 second, the other blits and SDL_Flip() take almost no time.
When I use fills instead of blits, the same problem happens.


Jimmy <@Jimmy>
Jimmy’s World.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20021113/de064ebf/attachment.pgp

I could be way off here, but I’m thinking that the 1/60th of a second
sounds an awful lot like the delay for a h/w sync on the monitor. I
believe SDL_Flip waits for a refresh before swapping the surfaces.

Yes, that’s what it should do.

As for the first blit taking 1/60th and the rest happening instantly
with the flip, how are you measuring this? In either case they should
all appear to take place at 1/60th a second since the flip would make
them visible.

If you’re just fprinting or cout-ing (I’m aware neither of those are
words) it might be that they get caught in a buffer when the delay takes
place for the flip making the following blits appear to take place
instantly. Try flusing the buffer each time you print your debugging
text (assuming this is how you were measuring the blits).

I’m measuring this like this:

int t0, t1;

t0 = SDL_GetTicks();
SDL_BlitSurface(…)…
t1 = SDL_GetTicks();


printf("%d", t1-t0);–
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!

Martin Konrad wrote:

t0 = SDL_GetTicks();
SDL_BlitSurface(…)…
t1 = SDL_GetTicks();

GetTicks precision is about ±10msec, so using it for a benchmark is not
correct for calls fast as SDL_BlitSurface!

Try something like:

t0 = SDL_GetTicks();
for(i=0; i<100; i++ )
SDL_BlitSurface(…)…
t1 = SDL_GetTicks();

t2 = SDL_GetTicks();
for(i=0; i<100; i++ )
SDL_Flip…)
t3 = SDL_GetTicks();

In this way you SHOULD be able to understand in a more reliable way
where your time is lost (and probably it is in SDL_Flip for the hw
refresh sync).

Bye,
Gabry

Martin Konrad wrote:

t0 = SDL_GetTicks();
SDL_BlitSurface(…)…
t1 = SDL_GetTicks();

GetTicks precision is about ±10msec, so using it for a benchmark is not
correct for calls fast as SDL_BlitSurface!

Try something like:

t0 = SDL_GetTicks();
for(i=0; i<100; i++ )
SDL_BlitSurface(…)…
t1 = SDL_GetTicks();

t2 = SDL_GetTicks();
for(i=0; i<100; i++ )
SDL_Flip…)
t3 = SDL_GetTicks();

In this way you SHOULD be able to understand in a more reliable way
where your time is lost (and probably it is in SDL_Flip for the hw
refresh sync).

The precision is not the problem.
For 1/60 second I get a value between 16 and 17, and it’s definately lost
with the first blit or fill. So, I get either 0 or 16/17.

Testing the time with 100x SDL_Flip() and nothing else doesn’t help. The
time is only lost when there are about 20 or more blits in the main loop with
both blits and SDL_Flip().–
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!

Martin Konrad wrote:

t0 = SDL_GetTicks();
SDL_BlitSurface(…)…
t1 = SDL_GetTicks();

GetTicks precision is about ±10msec, so using it for a benchmark is not
correct for calls fast as SDL_BlitSurface!

This isn’t exactly true. SDL_Delay has a 10msec granularity,
SDL_GetTicks is accurate < 10msec.

For example

Uint32 lastTicks = SDL_GetTicks();
for (Uint32 i=0; i<100000; i++) {
Uint32 newTicks = SDL_GetTicks();
if (newTicks!=lastTicks)
cout << "Newticks: " << newTicks-lastTicks << endl;
lastTicks = newTicks;
}

Will spit out lots of 1’s and some higher numbers where the scheduler
gave other processes a chance to work. Now if you add a SDL_Delay(1);
in the for you’ll see lots of 9’s, 10’s and 11’s.

Which, unfortunately doesn’t solve the original problem. :(On Wed, 2002-11-13 at 11:29, Gabriele Greco wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Jimmy <@Jimmy>
Jimmy’s World.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20021113/7518cc2b/attachment.pgp

In this way you SHOULD be able to understand in a more reliable way
where your time is lost (and probably it is in SDL_Flip for the hw
refresh sync).

The precision is not the problem.
For 1/60 second I get a value between 16 and 17, and it’s definately lost
with the first blit or fill. So, I get either 0 or 16/17.

Maybe SDL is doing something internal to prepare the surface for
access. If it’s the first time you’re using it. Just for a lark, try
locking & unlocking the surface instead of blitting to it.
Theoretically it would have to do the same thing internally to allow you
access to the pixels.

Maybe someone can enlighten us here a bit about the magical
inner-workings of surfaces and how they are managed internally? If this
problem is new to XP for you, maybe it’s the new version of DirectX that
is doing some kind of preperation for first access.>

Testing the time with 100x SDL_Flip() and nothing else doesn’t help. The
time is only lost when there are about 20 or more blits in the main loop with
both blits and SDL_Flip().

Jimmy <@Jimmy>
Jimmy’s World.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20021113/ab5ce8cb/attachment.pgp

It would help to post some (as minimal as possible) source. All I can
say without that is that 1/60sec sounds vsync-related.On Wed, Nov 13, 2002 at 07:08:36PM +0100, Martin Konrad wrote:

The precision is not the problem.
For 1/60 second I get a value between 16 and 17, and it’s definately lost
with the first blit or fill. So, I get either 0 or 16/17.

Testing the time with 100x SDL_Flip() and nothing else doesn’t help. The
time is only lost when there are about 20 or more blits in the main loop with
both blits and SDL_Flip().


Glenn Maynard

Of course it is vsync-related. But the problem is, why is this time consumed
by the blits and not by SDL_Flip(). And why doesn’t this problem appear when
I’m only doing 5 blits per frame and not 20 or more? And why are my programs
running so slow?> On Wed, Nov 13, 2002 at 07:08:36PM +0100, Martin Konrad wrote:

The precision is not the problem.
For 1/60 second I get a value between 16 and 17, and it’s definately
lost
with the first blit or fill. So, I get either 0 or 16/17.

Testing the time with 100x SDL_Flip() and nothing else doesn’t help. The
time is only lost when there are about 20 or more blits in the main loop
with
both blits and SDL_Flip().

It would help to post some (as minimal as possible) source. All I can
say without that is that 1/60sec sounds vsync-related.


+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!

In this way you SHOULD be able to understand in a more reliable way
where your time is lost (and probably it is in SDL_Flip for the hw
refresh sync).

The precision is not the problem.
For 1/60 second I get a value between 16 and 17, and it’s definately
lost
with the first blit or fill. So, I get either 0 or 16/17.

Maybe SDL is doing something internal to prepare the surface for
access. If it’s the first time you’re using it.

I’m running the loop about 2000 times. And I get the same values every time.
So, it’s always the first blit of the surface every frame, and not only in
the first frame.

Just for a lark, try
locking & unlocking the surface instead of blitting to it.

Yes, I’ll try this.

Theoretically it would have to do the same thing internally to allow you
access to the pixels.

Maybe someone can enlighten us here a bit about the magical
inner-workings of surfaces and how they are managed internally? If this
problem is new to XP for you, maybe it’s the new version of DirectX that
is doing some kind of preperation for first access.

Why must a hw-surface be prepared? And why isn’t it prepared with only 5
blits per frame?

I had DirectX8 installed previously, too. And the problem doesn’t only
appear on my own computer, but also on my brother’s and 3 other’s I know.–
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!

I’d expect that the “flip” call is telling it to flip at the next vsync,
and that doesn’t have to actually block unless you try to lock the
surface again, so the vsync delay is being postponed to the next lock.
Don’t know why the number of blits would affect it, though. Source?On Wed, Nov 13, 2002 at 09:20:23PM +0100, Martin Konrad wrote:

It would help to post some (as minimal as possible) source. All I can
say without that is that 1/60sec sounds vsync-related.

Of course it is vsync-related. But the problem is, why is this time consumed
by the blits and not by SDL_Flip(). And why doesn’t this problem appear when
I’m only doing 5 blits per frame and not 20 or more? And why are my programs
running so slow?


Glenn Maynard

Martin Konrad wrote:

The strange thing is that when I only
use about 5 blits, everything is fine, ie. the blits take almost no
time at all, and SDL_Flip() is waiting about 1/60 second for sync.
But when I do about 20 blits, the first blit takes 1/60 second, the
other blits and SDL_Flip() take almost no time. When I use fills
instead of blits, the same problem happens.

Maybe you’re reaching a driver or hardware-specific limit on the number
of blits or operations that can be queued for asynchronous execution?
Have you tried doing 40 blits, or 60, to see if the performance degrades
further? It might be a one-time penalty that you pay for more than N
blits that won’t prove significant when a lot more blits are being done.

The weird part of what you’ve said is that you’ve implied that the 1st
blit can take longer in the 20-blit version even before the code 'knows’
that there are more than 5 blits in total. If it only applies to the 2nd
frame and so on, it would make more sense.–
Kylotan
http://pages.eidosnet.co.uk/kylotan

Martin Konrad wrote:

The strange thing is that when I only
use about 5 blits, everything is fine, ie. the blits take almost no
time at all, and SDL_Flip() is waiting about 1/60 second for sync.
But when I do about 20 blits, the first blit takes 1/60 second, the
other blits and SDL_Flip() take almost no time. When I use fills
instead of blits, the same problem happens.

Maybe you’re reaching a driver or hardware-specific limit on the number
of blits or operations that can be queued for asynchronous execution?

Do you know a good way of handling the many blits then?
I’m not sure if the many blits are the real problem, because the other
programs that run too slow don’t do that many blits.

Have you tried doing 40 blits, or 60, to see if the performance degrades
further? It might be a one-time penalty that you pay for more than N
blits that won’t prove significant when a lot more blits are being done.

The weird part of what you’ve said is that you’ve implied that the 1st
blit can take longer in the 20-blit version even before the code 'knows’
that there are more than 5 blits in total. If it only applies to the 2nd
frame and so on, it would make more sense.

I tried the program a bit more, and unfortunately I must admit that I wrote
something wrong about the numbers. But, the numbers I got recently were even
more strange. And there’s a difference betwenn fill and blit numbers.

The main loop currently looks like this:

for (int i = 0; i < 200; i++) {
	int t1, t2, ta, tb;
	
	for (int j = 0; j < 10; j++) {
		ta = SDL_GetTicks();
		SDL_FillRect(screen, 0, 0xABCD);
		/*SDL_BlitSurface(srfc1, 0, screen, 0);
		SDL_BlitSurface(srfc1, 0, screen, 0);
		SDL_BlitSurface(srfc1, 0, screen, 0);
		SDL_BlitSurface(srfc1, 0, screen, 0);*/
		tb = SDL_GetTicks();
		printf("blit: %3d\n", tb - ta);
	}
	
	t1 = SDL_GetTicks();
	SDL_Flip(screen);
	t2 = SDL_GetTicks();
	printf("flip: %3d\n----------\n", t2-t1);
}

(At the beginning of the program I’m switching to high priority.)
srfc1 is a 16 bit hw-surface with a size of 64x64 pixels.

But even if this program can’t put out any values that say something
correct, why are my programs running too slow on XP? They run much slower than on
Win98.–
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!

I think I read recently that the Windows/DirectX version has been
changed to use an asynchronous flip. This means that SDL_Flip() dosen’t
block but the next blit could block instead (depends if the flip has
catually happened in the meantime). This would explain the behaviour
with 20 blits or more, it doesn’t really explain why the behaviour is
different with 5 blits.

Martin Konrad wrote:> Hello

I’ve a big speed problem with my SDL programs, since I installed Windows XP.
Although they don’t do anything special, they run much too slow. They’re
just using some hardware surfaces and the video mode is
SDL_HWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN in 16 bit. I don’t think my Radeon is too slow for the
graphics.

I wrote a little test program, that just sets the video mode and has a
little main loop, which does blits or fills and SDL_Flip(). I tested the speed
with SDL_GetTicks(). The strange thing is that when I only use about 5 blits,
everything is fine, ie. the blits take almost no time at all, and SDL_Flip() is
waiting about 1/60 second for sync. But when I do about 20 blits, the first
blit takes 1/60 second, the other blits and SDL_Flip() take almost no time.
When I use fills instead of blits, the same problem happens.

Can anyone explain this, or help me with the speed problem?

Thanks to all of you for trying to solve my problem.
I’m using DirectX directly now, and it works fine.
Bye.