On mercredi 24 septembre 2008, Vivian Meazza wrote: > Curtis, > > > > Finally getting somewhere on this issue. Using the Seahawk with Apr source > and data, performance is very satisfactory. Generally good frame rates, > with just the odd stagger, which judging by the odd video I have seen on > YouTube, seems to be the general case. Using cvs-head source and data, with > everything else the same, severe staggering, poor frame rates, virtually > unusable. Using cvs-head source, but reverting the data to Apr, although > that breaks quite a bit of fg, framerates are restored, and staggers are > back to "normal". > > > > So, I think we are on to something with the nasal hypothesis. I'm now > trying to eliminate the scripts one by one. And kicking myself for not > getting here faster. > > > > Vivian > > > > > > > > -----Original Message----- > From: Curtis Olson [mailto:[EMAIL PROTECTED] > Sent: 22 September 2008 23:36 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system > > > > On Mon, Sep 22, 2008 at 5:23 PM, James Turner wrote: > > On 22 Sep 2008, at 23:05, Vivian Meazza wrote: > > A binary search, which I'm also trying, takes days. At some point we > > left > > OSG 2.4, used an interim version, then migrated to osg 2.6. An osg > > rebuild > > here takes well over an hour. So far, I've come about halfway > > forward from > > Apr, which is the last-known-good I have. The total rebuild takes > > about > > 3hrs. I can manage to find time for about 1 a day in all. > > Well, being selfish, one around the start of August would rule my > changes in or out - but if you're slogging through the binary search, > I'll leave you to it. > > > I have no evidence that it's anything that you have done, although > > AJ might > > take a different view. Still have hash.c in my sights. > > Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK > is hasn't been touched in a good long time. > > > Here's another idea to toss into the mix ... > > What aircraft is being flown in these tests? If hash.c looks like a > hotspot, that could also be triggered by an aircraft that had a lot of new > nasal code added. Or it could be newly added default system nasal code? I > don't know how much of FlightGear functions anymore without nasal, but > disabling the default nasal directory and picking an aircraft with little > or no embedded nasal code might also be an interesting test. We could > possibly have crossed a threshold in terms of the amount of nasal code used > for some particular aircraft? > > Regards, > > Curt.
Only, a question: Does the stutter comes up when testing with the c172p (over KSFO for instance) , that AC has not Nasal script. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
