Drew wrote:
I don't think anyone suggested there was a bug...I'm just trying to
improve performance. I'm writing a simulator that interfaces with
FlightGear, using FlightGear as the scenery generator on the same PC. The program runs great, it's just that FlightGear gets interrupted
easily by other programs, and is jumpy in my particular application. If you open and close a window, you can see how FlightGear freezes
momentarily.
Hi Drew,
Typically, operating systems run their windows manager and user interface stuff at a high priority (which makes the operating system seem snappy and responsive.) So opening/closing windows, resizing them, moving them, etc. will kill performance of anything else you are running. That's usually ok and you never notice it if all you are doing is running email and web browsing and word processing type apps, but it's a killer if you are expecting to sustain performance of a real time 3d application at the same time.
What I want to do is bump up the priority of FlightGear so that it is
more robust. The problem I'm having is that once I do, everything
else comes to a screeching halt. Therefore, I want FlightGear to be
more conservative with its processor usage, so I can increase its
priority without adversely affecting other processes.
The proposed sleep() based frame rate throttling patch may help with that because it puts FG to sleep every frame (which should automatically yield the CPU to anything else in the run queue.) However, the proposed patch also messes up the consistancy of frame rates because the way sleep() is implimented, you can't actually sleep() for the exact time you want. You never sleep less than the requested amount but you often/usually sleep somewhat longer than the requested time. So if you are trying to eliminate frame rate jitter, this is not going to help you reach a perfect solution (but it may improve things under certain circumstances for certain people.)
I don't understand what you mean about 'using them or let them go to
waste'. If it takes FlightGear 10 ms to execute a frame, and I only
need a frame time of 33 ms, what gain is there in FlightGear hijacking
those other 23 ms, even if it is just idle time? Just because it's
taking those cycles doesn't mean it's using them productively.
The issue is that FG needs to hijack these CPU cycles to do precise timing and to know when to move on to work on the next frame. If you don't mind dropping frames right and left, a sleep() based solution will free up those cpu cycles for other apps to use, but you may sacrifice consistancy of frame rate (or at least you will never be able to achieve perfectly consistant frame rates.)
I have a specific application that requires better timing than sleep() can provide, so I need the original busy-wait solution or something very close to it. I don't mind adding a sleep() based throttling mechanism as well, but people who use it need to realize it's limitations.
Regards,
Curt.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
