Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Quoting Curtis L. Olson : Time out here! There are two reasons two throttle frame rate. 1. Conserve CPU time and leave more cpu time for other tasks. Using sleep() calls you can put FG asleep for a short time if it gets done drawing a frame early, leaving those cycles for other tasks. 2. Accurately control frame rate. Here you want to run at a fixed precise frame rate to achieve smooth, jitter free rendering. For instance, if you can't quite sustain 60hz consistanty, you might want to throttle back to 30hz. The problem is that this new patch throws away the second reason in favor of the first. When I throttle to 20hz, I get 19hz. When I throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the application to sleep does terrible things to timing accuracy, because typically the application can only wake up during a kernel trap, and if you miss the vertical refresh by even 1 millesecond, you drop a frame and get animation jitters. Maybe we need to figure out how to satisfy both needs, but we can't just blindly dispense with reason #2 when a new need comes along. Maybe we need separate options, such as --cpu-friendly-inaccurate-throttle-with-sleep-hz= and --frame-rate-accurate-throttle= Thoughts? I think we need to tread a bit more carefully on this one, especially since I have a side project that employs this option (well, used to employ this option) :-( to achieve accurate frame rate timing and smooth animation. Maybe it is doable to sleep for a millisecond less than computed and achieve the targeted framerate with the loop. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I wrote:
Maybe it is doable to sleep for a millisecond less than computed and achieve
the
targeted framerate with the loop.
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
if ( throttle_hz 0.0 scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Frederic,
Your patch helps, but typically the semantics of sleep() commands is
they will sleep at least as long as the requested time (up to the kernel
trap timing resolution) so I am still seeing dropped frames, although
not nearly as bad. If the kernel timing resolution is different than
the monitor refresh resolution with no convenient multiples (i.e. 60hz
vs 100hz), it's always going to be imperfect.
Regards,
Curt.
Frederic Bouvier wrote:
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
if ( throttle_hz 0.0 scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://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
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Sorry to borrow this thread for my own purpose, but I'm trying to
achieve goal 1 with as little impact on goal 2 as possible. I tried
this patch with mixed results.
In Windows, adding this code did absolutely nothing to the processing
time...it remains at 99% usage whether I throttle back to 60, 30, or 1
Hz. However, in an effort to debug this problem, I switched the
compiler flags (VisualStudio) from 'release' to 'debug' mode. Once
iit was compiled in 'debug' mode, the throttle_frame_rate actually
yielded some processing ttime for other processes. It runs better,
but still not ideal. Anyway, does anyone have any hypotheses as to
what's causing this difference?
BTW, I was going to suggest having a 'cumulative' target time that
gaurantees an average frame time rather than a minimum frame time, but
it appears Fredric beat me to the punch. :)
Drew
On Wed, 09 Mar 2005 09:51:47 -0600, Curtis L. Olson
[EMAIL PROTECTED] wrote:
Time out here!
There are two reasons two throttle frame rate.
1. Conserve CPU time and leave more cpu time for other tasks. Using
sleep() calls you can put FG asleep for a short time if it gets done
drawing a frame early, leaving those cycles for other tasks.
2. Accurately control frame rate. Here you want to run at a fixed
precise frame rate to achieve smooth, jitter free rendering. For
instance, if you can't quite sustain 60hz consistanty, you might want to
throttle back to 30hz.
The problem is that this new patch throws away the second reason in
favor of the first. When I throttle to 20hz, I get 19hz. When I
throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the
application to sleep does terrible things to timing accuracy, because
typically the application can only wake up during a kernel trap, and if
you miss the vertical refresh by even 1 millesecond, you drop a frame
and get animation jitters.
Maybe we need to figure out how to satisfy both needs, but we can't just
blindly dispense with reason #2 when a new need comes along.
Maybe we need separate options, such as
--cpu-friendly-inaccurate-throttle-with-sleep-hz= and
--frame-rate-accurate-throttle=
Thoughts? I think we need to tread a bit more carefully on this one,
especially since I have a side project that employs this option (well,
used to employ this option) :-( to achieve accurate frame rate timing
and smooth animation.
Curt.
Erik Hofman wrote:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv28989
Modified Files:
main.cxx
Log Message:
Frederic Bouvier:
Norman Vine wrote :
Frederic Bouvier writes:
Quoting Andy Ross:
* Hopefully in a CPU-friendly way. I know that older versions of
the NVidia drivers did this by spinning in a polling loop
inside the driver. I'm not sure if this has been fixed or not.
From my experience, the latest non-beta Windows NVidia driver seems to
eat CPU
even with sync to vblank enabled. The CPU usage is always 100%.
Buried in the PPE sources is a 'hackish' but portable way to limit CPU
usage if the desired framerate is met
/*
Frame Rate Limiter.
This prevents any one 3D window from updating faster than
about 60Hz. This saves a ton of CPU time on fast machines.
! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
*/
static ulClock *ck = NULL ;
if ( frame_rate_limiter )
{
if ( ck == NULL )
{
ck = new ulClock ;
ck - update () ;
}
int t_ms = (int) ( ck-getDeltaTime() * 1000.0 ) ; /* Convert to ms */
if ( t_ms 16 )
ulMilliSecondSleep ( 16 - t_ms ) ;
}
I implemented the method pointed out by Norman. It works great on windows
and saves me a lot of CPU cycles. This way, I can get the same framerate in
moderately populated areas and have CPU idle 50% of the time instead of
wildly looping in the NVidia driver while waiting to sync on vblank.
It has been tested on Linux by Melchior. He saw the same gain in CPU cycles.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.193
retrieving revision 1.194
diff -C2 -r1.193 -r1.194
*** main.cxx 5 Jan 2005 05:45:38 - 1.193
--- main.cxx 9 Mar 2005 15:12:01 - 1.194
***
*** 223,226
--- 223,228
SGCloudLayer::enable_bump_mapping =
fgGetBool(/sim/rendering/bump-mapping);
+ bool scenery_loaded = fgGetBool(sim/sceneryloaded) ||
fgGetBool(sim/sceneryloaded-override);
+
// Update the elapsed time.
static bool first_time = true;
***
*** 231,241
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
! if ( throttle_hz 0.0 ) {
// simple frame rate throttle
! double dt = 100.0 / throttle_hz;
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: Frederic, Your patch helps, but typically the semantics of sleep() commands is they will sleep at least as long as the requested time (up to the kernel trap timing resolution) so I am still seeing dropped frames, although not nearly as bad. If the kernel timing resolution is different than the monitor refresh resolution with no convenient multiples (i.e. 60hz vs 100hz), it's always going to be imperfect. Here is some additional data. I note the requested sleep time, then measure the actual sleep time. If the sleep time is greater thanTimes are in milleseconds ... requested = 5 actual = 6.898 requested = 6 actual = 7.998 requested = 6 actual = 7.269 requested = 5 actual = 6.358 requested = 2 actual = 3.230 requested = 7 actual = 8.972 So it looks like at least on the linux kernel-2.6.x you can get pretty fine sleep resolution, but it's always a few milleseconds more than you asked for. Usually the sleep overshoot is 1,2, or even 3 milleseconds, but I did some tracking and saw it as high as 17 milleseconds on occasion. Backing off and sleeping 1 ms less than the target helped, but you'd probably have to back off 2-3 for more consistant results, and at least 17ms for perfect results. I don't think is possible to do accurate millesecond timing with a sleep command on consumer operating systems. You can get close, but not close enough, because if you drop even one frame a second, your eye can spot it and notice the animation jitter. Regards, Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: Maybe we need separate options, such as --cpu-friendly-inaccurate-throttle-with-sleep-hz= and --frame-rate-accurate-throttle= Thoughts? I think we need to tread a bit more carefully on this one, especially since I have a side project that employs this option (well, used to employ this option) :-( to achieve accurate frame rate timing and smooth animation. What was the original bug report? Currently, FlightGear will look CPU-limited to the OS, which means that short running or I/O bound processes will get priority anyway. What is the application that needs extra CPU, and are we sure that it's not being performance limited in some other way? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I asked: What is the application that needs extra CPU, and are we sure that it's not being performance limited in some other way? Aha! Drew wrote: In Windows, adding this code did absolutely nothing to the processing time...it remains at 99% usage whether I throttle back to 60, 30, or 1 Hz. [...] Once iit was compiled in 'debug' mode, the throttle_frame_rate actually yielded some processing ttime for other processes. It runs better, but still not ideal. Wait, that's not a bug report about processing time available for other proceses at all. That's a bug report about the total CPU usage being at 99%, which is irrelevant. If the CPU is available, then of course FlightGear should use it all; you can't save up cycles -- either use them now or let them go to waste. Which app are you running that is going too slow, and how much CPU do you think it needs? Those are the important questions. Your OS (yes, even windows) has an elaborate scheduler which is designed to make sure that all processes get the CPU they need to do their job. Sometimes you need to tweak things, but those circumstances are rare. I strongly suspect we're chasing a ghost on this one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Wait, that's not a bug report about processing time available for other proceses at all. That's a bug report about the total CPU usage being at 99%, which is irrelevant. If the CPU is available, then of course FlightGear should use it all; you can't save up cycles -- either use them now or let them go to waste. 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. 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. 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. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
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 Olsonhttp://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
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Thanks for the quick response. 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. I understand that. I'm not looking to change the FlightGear baseline...just a solution that does what I need. How precise is the timing of the naitive-gui ? If I have my simulation use a blocking socket to receive messages, this can provide the interrupt to schedule my simulation. The only problem there would be that if a packet is dropped, the simulation will miss a frame (unlikely if they're on the same PC). Does native-gui run in its own thread, or is it limited to FlightGear's frame rate? I'm just brainstorming here...I still don't know what my ideal solution is. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: 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. I don't wonder, though, if that isn't due to locking inside GDI (or VM swap -- how much memory do you have?) and not CPU usage. Applications doing 3D rendering don't coexist well with things that need to draw to the screen. Can you try something purely CPU intensive (like a perl script that counts to a few million) and see if you can notice the same behavior? My guess is that tuning FlightGear's CPU usage isn't going to get us much. Conversely, can you compare FlightGear to other spin on the cpu 3D applications like games? Do they exhibit the same issues? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I don't wonder, though, if that isn't due to locking inside GDI (or VM swap -- how much memory do you have?) and not CPU usage. Applications doing 3D rendering don't coexist well with things that need to draw to the screen. Can you try something purely CPU intensive (like a perl script that counts to a few million) and see if you can notice the same behavior? My guess is that tuning FlightGear's CPU usage isn't going to get us much. Conversely, can you compare FlightGear to other spin on the cpu 3D applications like games? Do they exhibit the same issues? I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Doesn't X-Plane run full screen, or does it now support running in a window. If you are running x-plane full screen you are probably comparing apples to oranges here. Regards, Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Frederic,
I've been hacking on your patch a bit more and I see that we rarely
oversleep by more than 2ms. So backing off by 2ms (instead of 1ms)
seems to work pretty well here. I also switched to doing all the math
in microseconds rather than milleseconds (and converting at the latest
possible moment) in hopes that it would be slighty more accurate.
This is only tested on the 2.6.x kernels. I suspsect that usleep() will
be much less accurate on 2.4.x kernels. I don't know if anyone else is
using the frame rate throttling feature so it may not matter?
Regards,
Curt.
Frederic Bouvier wrote:
I wrote:
Maybe it is doable to sleep for a millisecond less than computed and achieve
the
targeted framerate with the loop.
Could you try this patch :
cvs -z4 -q diff -u main.cxx (in directory
I:\FlightGear\cvs\FlightGear\src\Main\)
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.194
diff -u -r1.194 main.cxx
--- main.cxx9 Mar 2005 15:12:01 - 1.194
+++ main.cxx9 Mar 2005 16:53:34 -
@@ -233,12 +233,11 @@
double throttle_hz = fgGetDouble(/sim/frame-rate-throttle-hz, 0.0);
if ( throttle_hz 0.0 scenery_loaded ) {
-static double remainder = 0.0;
-
// simple frame rate throttle
-double dt = 100.0 / throttle_hz + remainder;
+double dt = 100.0 / throttle_hz;
int wait = dt / 1000;
-remainder = dt - ( wait * 1000.0 );
+if ( wait 0 )
+wait -= 1;
current_time_stamp.stamp();
int t_ms = (int) ( ( current_time_stamp - last_time_stamp ) / 1000 ) ;
/* Convert to ms */
@@ -246,6 +245,9 @@
ulMilliSecondSleep ( wait - t_ms ) ;
}
current_time_stamp.stamp();
+while ( current_time_stamp - last_time_stamp dt ) {
+current_time_stamp.stamp();
+}
} else {
// run as fast as the app will go
current_time_stamp.stamp();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Curtis Olsonhttp://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
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. And the proper way to do that optimization is to figure out what the actual symptom is. Which requires testing a hypothesis (is it due to CPU usage?) by changing one parameter (open a window vs. run a looping perl script) at a time in order to isolate the symptom (complicated window system interaction vs. pure CPU usage). It seems to me that you have gone backwards: you picked a favorite fix before knowing what the problem is. The bottom line is that performance analysis is really complicated. You can't cook it down to a single number like CPU usage (or load -- a equally flawed Unix favorite) if you really want to fix a problem. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote : Frederic, I've been hacking on your patch a bit more and I see that we rarely oversleep by more than 2ms. So backing off by 2ms (instead of 1ms) seems to work pretty well here. I also switched to doing all the math in microseconds rather than milleseconds (and converting at the latest possible moment) in hopes that it would be slighty more accurate. This is only tested on the 2.6.x kernels. I suspsect that usleep() will be much less accurate on 2.4.x kernels. I don't know if anyone else is using the frame rate throttling feature so it may not matter? Do you want to check it that way or do you want separated behavior : exact framerate vs CPU friendly ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
It seems to me that you have gone backwards: you picked a favorite fix before knowing what the problem is. The bottom line is that performance analysis is really complicated. You can't cook it down to a single number like CPU usage (or load -- a equally flawed Unix favorite) if you really want to fix a problem. Hey Andy, I know for a fact that FlightGear uses every available processor cycle. I also know that if I increase the priority of FlightGear, it takes cycles away from other processes. In my application, I need FlightGear to run at 640x480 res at 30 Hz (the output is a TV), but I've seen FlightGear run well at 1400x1050 and 60 Hz. Therefore, I *know* FlightGear is using much more CPU cycles than it needs, and I know that if there's a way to free up these extra cycles, I can run FlightGear at a higher priority without interrupting other processes. Does this not seem like a rational train of thought? I admit, I'm new to this type of performance optimization. What do *you* think the problem is? Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
X-Plane opens in a 1024x768 borderless window, which doesn't fill my laptop display at 1400x1050. However, when I reduce and restore windows, I can tell that the X-Plane process preempts the windows processes because the windows open slowly. X-Plane still yields some time to the windows, though, unlike what happens if I increase the priority of FlightGear. BTW, this patch with the Sleep calls still doesn't seem to be working for me...when I increase flightgear's priority it still completely takes over the system. Is there another thread that might be doing this? Drew On Wed, 09 Mar 2005 13:53:36 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Drew wrote: I don't know the answer to this. My computer has 512 megs, which is a lot more than FlightGear uses. I'm not really interested in how other 3D apps, including games, work...I have a specific application, and I want to optimize the code for this purpose, regardless of what the status quo is. FWIW, I've tried an interface with x-plane, and it doesn't have the same problem. Too bad it isn't open-source. Doesn't X-Plane run full screen, or does it now support running in a window. If you are running x-plane full screen you are probably comparing apples to oranges here. Regards, Curt. -- Curtis Olsonhttp://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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
