Hi,
I have a problem under Linux with slow keyboard response. When
running the SDLgears example I get a decent framerate (70fps) but after
pressing a key it is 10-15 seconds before I get a response! Under
windows it ran perfectly. I did not modify the code, so why is Linux so
slow?
Thanks in advance for any help,
DavidHi,
I have a problem under Linux with slow keyboard response. When
running the SDLgears example I get a decent framerate (70fps) but after
pressing a key it is 10-15 seconds before I get a response! Under
windows it ran perfectly. I did not modify the code, so why is Linux so
slow?
SDL is pushing the X server as hard as it can, and so the X server takes
a while to respond to input. This is especially a problem for applications
that for some reason are using the built-in X server GL software rendering.
Suggestions are welcome. 
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Hi,
I have a problem under Linux with slow keyboard response. When
running the SDLgears example I get a decent framerate (70fps) but after
pressing a key it is 10-15 seconds before I get a response! Under
windows it ran perfectly. I did not modify the code, so why is Linux so
slow?SDL is pushing the X server as hard as it can, and so the X server takes
a while to respond to input. This is especially a problem for applications
that for some reason are using the built-in X server GL software rendering.Suggestions are welcome.
Would it help to renice the program - giving the X server a slightly higher
priority than the SDL program?
If this helps, it might be a good function to add to SDL to be able to change
process-priorities.
Unix:
int getpriority(int which, int who);
int setpriority(int which, int who, int prio);
Windows:
BOOL SetPriorityClass(HANDLE hProcess, DWORD Class)
DWORD GetPriorityClass(HANDLE hProcess)
Andreas–
| Andreas Schiffler aschiffler at home.com |
| Senior Systems Engineer - Deskplayer Inc., Buffalo |
| 4707 Eastwood Cres., Niagara Falls, Ont L2E 1B4, Canada |
| +1-905-371-3652 (private) - +1-905-371-8834 (work/fax) |
Mon, 15 Jan 2001 Sam Lantinga wrote:
Hi,
I have a problem under Linux with slow keyboard response. When
running the SDLgears example I get a decent framerate (70fps) but after
pressing a key it is 10-15 seconds before I get a response! Under
windows it ran perfectly. I did not modify the code, so why is Linux so
slow?SDL is pushing the X server as hard as it can, and so the X server takes
a while to respond to input. This is especially a problem for applications
that for some reason are using the built-in X server GL software rendering.Suggestions are welcome.
Hmm… Well, if there was a way to ask X (or GLX) how many commands are queued
up, the application could start sleeping for short moments when the queue gets
unreasonably long. Another way is to simply sync on a suitable command
occasionally, but that would probably result in the chance of the server having
nothing to do for a short moment every now and then. (Which is not desired if
we’re benchmarking the rendering speed.)
This, obviously, will only work if the delay is actualy caused by X queueing
up tons of commands. If it’s just the load in itself, then the only way is to
lower the frame rate - preferably to exactly match and sync to the video refresh
rate. Just slowing down the application to an arbitrary rate will nearly always
look worse than running it at full speed, but it does solve the server overload
problem, at least… Retrace sync + true page flipping or at least carefully
synced double buffering with blitting is the only way to get perfect results
with minimal system stress. (Oh, we got this retrace bit polling crap, of
course. :-/ RTLinux or RTAI could eliminate the problem with polling overhead
for cards without proper retrace IRQs, but that’s not very likely to be seen in
mainstream kernels, I’m afraid.)
And now we’re back to what makes me dig around in the Utah-GLX sources…
//David
…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’
Hi Sam!
Maybe SDL is failing to properly call Sync() at the right times…
Yep, the question is when is the right time?
Well, Syncing after polling for events seems to work ok, but to be on the
safe side, I’d suggest syncing after all I/O, i.e. sync after event polling
and after writing to the screen.
In fact, in the case of DGA, they have quite clear guidelines (I don’t know
xlib so well tho, but I assume the same).
According to the DGA documentation when the server is not capable of concurrent
access then it is very important to call XDGASync() before directly
accessing the framebuffer if a call to XDGAFillRectangle(),
XDGACopyArea() or XDGACopyTransparentArea() or any Xlib
rendering function has been made prior to such accesses.
I’ve found that if you stick to that you stay out of trouble completely (;–
Regards
Abraham
Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks
P.O. Box 3472, Matieland, Stellenbosch, 7602
Cell: +27 82 565 4451 - Tel: +27 21 887 8703
Http: http://www.frogfoot.net
Email: @Abraham_vd_Merwe
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010117/b5b7d600/attachment.pgp
@David_Williams wrote:
Hi,
I have a problem under Linux with slow keyboard response. When
running the SDLgears example I get a decent framerate (70fps) but after
pressing a key it is 10-15 seconds before I get a response! Under
windows it ran perfectly. I did not modify the code, so why is Linux so
slow?
Thanks in advance for any help,David
Ok, I have actually fixed this now. I had been using the Mesa GL drivers
without hardware accelaration, but installing NVIDIA 0.96 seems to have
fixed the problem. I guess it takes some strain off the X-server or
something.
David Williams wrote:
esuvs at warwick.ac.uk wrote:
Ok, I have actually fixed this now. I had been using the Mesa GL drivers
without hardware accelaration, but installing NVIDIA 0.96 seems to have
fixed the problem. I guess it takes some strain off the X-server or
something.
Another solution would be to get a dual-processor system
Except, errr, NVIDIA drivers, that might be a problem. Closed-source can
suck, hard.
~jeffrey :j