21 Nov
2006
21 Nov
'06
9:37 p.m.
On 11/21/06, Dominic Sacré <dominic.sacre(a)gmx.de> wrote:
On Tuesday 21 November 2006 21:42, Fons Adriaensen
wrote:
Well, this flag is not used in GL mode, so it's no surprise that it has no
effect there. But it looks like I should be using software surfaces in
SDL mode.
Do you have hardware accelerated OpenGL at all? Software emulated GL can
be dog slow (much slower than SDL), that's the main reason why I added
SDL support in the first place.
For comparison, on my machine, with 12 tracks, fullscreen 1280x960, I'm
getting about 30% CPU load using OpenGL. That's with an Athlon XP 3000+
and a cheap, 4 year old, passively cooled Nvidia card.
I've a similar Athlon/nvidia setup. If I use OpenGL as root with -f 0
then all is well. If I use the -f 0 as a normal user my CPU goes to
100%. Just using -g by itself doesn't cause the CPU to race, but it
can easily lock things up. (The keyboard locks up, the display
freezes, but the mouse still works) SDL mode is more stable and
doesn't seem to use the CPU any more than the OpenGL mode.
I assume
you're using SDL. If you can, try OpenGL, that should take
most of the work off the CPU.
Rather the opposite, see below.
Another thing you could try is to change both
occurences of
SDL_HWSURFACE in video.h to SDL_SWSURFACE. Does it make any
difference? On my machine it doesn't, so I wasn't sure what to use.
It does help a bit, but not with -g:
| -g
---------------------
HW | 33% 94%
SW | 22% 93% I've got an almost identical app
(Yass - not yet released). With 100 updates per second, 32 channels,
and the maximum scrolling speed it takes less than 1% of available CPU.
So it's definitely not X11 taking all the time.
Wow, 1%?! Is that using plain X11? Sounds almost too good to be true.
I think it goes without saying that I'd be interested in seeing your
code ;)
Dominic