Re: [Flightgear-devel] Re: opening window splash screen
Le vendredi 06 mai 2005 11:24 +0200, Melchior FRANZ a crit : * Ampere K. Hardraade -- Thursday 05 May 2005 20:43: Just an idea: would it be possible to throw in some random and irrelevent messages in there as well, such as tying pilot's shoelase, so people can have a laugh or two while waiting for FlightGear to load? No. There are only a few messages at strictly defined points. There's no way to add further ones. We would have to put renderer and initialization in separate threads to do anything like that. The only possibility for aircraft designers is to put a message into the optional title (/sim/startup/splash-title). The result is pretty good. Don't try to be complicate. Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: opening window splash screen
David Luff wrote Ditto Cygwin for long startup times. I've taken a look in the past, and loading the airport and nav data consumes the vast bulk of the time. This happens before any rendering (and before the splash-screen appears, which I assume Melchior's patch fixes). FGFS start-up times under Cygwin have become so long that it is possible to brew a cup of coffee while waiting ... some might think this useful. Kettle's on :-) Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: opening window splash screen
Melchior FRANZ wrote * Vivian Meazza -- Thursday 05 May 2005 09:44: FGFS start-up times under Cygwin have become so long that it is possible to brew a cup of coffee while waiting ... some might think this useful. Oh. I hope you mean that the startup time has become much too long over time, and not that this patch made it worse. I don't think that the patch has a noticable effect, neither positive nor negative. Except that it possibly improves the perception and makes it feel a bit faster. And that will further improve with progress info. Yes, quite right. Sorry to have given the impression that the slow start was related to your patch. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: opening window splash screen
On 5 May 2005, at 09:18, Melchior FRANZ wrote:Oh. I hope you mean that the startup time has become much too long over time, and not that this patch made it worse. I don't think that the patch has a noticable effect, neither positive nor negative. Except that it possibly improves the perception and makes it feel a bit faster. And that will further improve with progress info. What has slowed down fgfs in the last time was the migration to the new database formats -- not because they are read less effectively, but simply because they contain much more data. That's at least the impression that I got from valgrind (http://www.valgrind.org/) runs. I don't have much time to delve into this right now (hah!), but I have some log calls in my local build, which have been fairly consistent (haven't tested since your changes, Melchior - when I do, I'll post those numbers).That said, here are the numbers I have (for three runs) time to run fgMainInit: 44 sec 32 sec 29 sectime between idle_state 0 and idle_state 1000 33 sec 10 sec 10 sec(wall-clock) time after hitting idle_state 1000 before scene appears consistently about 25 - 30 secondsComments - the first phase (lots of database traversal) is obviously very dependant on file system cache hot-ness, and the second phase similarly. The third phase, *after* idle-state 1000, is the bit I was referring to when I talked about starvation; while it's doing this wait, I see the splash screen, and see log output from subsystems frequently (traffic manager, clouds, ephemeris), but it seems to sit there for ages before showing the cockpit + scenery.I ran a statistical profiler on the startup, and it didn't get all the way through startup before it hit it's log size limit, but the first part was spending huge amounts of time parsing data files, especially doing string - to float parsing. Doing the equivalent of 'atof' was something like 11% of the total time for the profile I ran.Lazyness is the way to go here, I'd suggest. Or binary file formats.James -- Ignorance more frequently begets confidence than does knowledge. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: opening window splash screen
Melchior FRANZ wrote: * Curtis L. Olson -- Wednesday 04 May 2005 22:44: I like the idea. One problem on the windows platform is lack of feedback from the graphical launcher that anything happened when you clicked run. It's easy to click run a couple times and end up with 5 copies of FG running Yes, but not only that. As I mentioned in the other message (with my first, cheesy approach): it takes much too long now until the window appears. So, if you want to do something useful while fgfs loads, and switch to another virtual desktop, the fgfs window suddenly pops up there. And finally: it's a pity that the splash screens are only visible for a short time before the 3D window is shown, which kind of defeats their purpose. So, I can commit this? (It's much cleaner than the patch makes it look like! :-) I'll fix bugs that I may have missed, and we can still revert if there pops up a serous problem. Sounds good to me. I'm sure lots of people will holler if anything breaks. 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] Re: opening window splash screen
On 04/05/2005 at 23:40 Melchior FRANZ wrote: * James Turner -- Wednesday 04 May 2005 23:14: Minor partial objection - the Mac startup is dog slow (like 90 seconds to get to a usable plane in the C172 and SFO), and I think at least part of the problem is the 'init while idle' scheme - FG wastes too much time doing rendering type things Ditto Cygwin for long startup times. I've taken a look in the past, and loading the airport and nav data consumes the vast bulk of the time. This happens before any rendering (and before the splash-screen appears, which I assume Melchior's patch fixes). Melchior FRANZ wrote: I thought about a progress bar, or better: an info line that says: initializing navigation data, initializing airport data, etc. That entertains people a lot and makes the startup time appear shorter. Excellent idea! Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: opening window splash screen
Melchior FRANZ wrote: * James Turner -- Wednesday 04 May 2005 23:14: Minor partial objection - the Mac startup is dog slow (like 90 seconds to get to a usable plane in the C172 and SFO), and I think at least part of the problem is the 'init while idle' scheme - FG wastes too much time doing rendering type things Hardly. It isn't rendering anything while it's calling the idle loop. Only when the initialization is done (idle_state == 1000) the rendering fun begins. And this patch does only move parts, not add any. I'll wait until you can provide some numbers to back up your suspicion. :-) What can happen though if we interleave with the rendering loop on init, is that for slower displays that take a non-trivial amount of time to render (or even clear the buffer) then init times can be substantially slowed. I thought about a progress bar, or better: an info line that says: initializing navigation data, initializing airport data, etc. That entertains people a lot and makes the startup time appear shorter. Some feedback is good, but a reasonable progress bar probably would require some threading which IMHO is not worth it. Some textual messages that change periodically with init progress is probably a good thing though if it can be done pretty cleanly ... 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
