On Sun, Jun 1, 2008 at 10:25 AM, Frederic Bouvier wrote:
> Hi,
>
> looking for why startup is so slow, I found at least three causes that
> could be addressed :
>
> 1. FGAIAircraft class throws hundreds of FP_Inactive exceptions where a
> simple boolean return value could have made the job ( the try/catch bloc
> is in the calling code )
> 2. UpdateFunctor() / testNan in modelmgr.cxx also throws a lot of
> sg_range_exception exceptions where again a simple test in the calling
> function could have made the job,
> 3. The scenegraph is drawn again and again while the splash screen is
> visible, slowing down the initialisation phase even more.
>
> Exception throwing is very slow on some platform and should be reserved
> to exceptional case.
>
> Solving 1. and 2. is easy and I have a patch ready. But 3. needs a
> little bit of search for me. Any advice from the scenegraph gurus ? I
> guess a osg::Switch node could prevent the scenegraph to be
> updated/culled/drawn while the scenery is loading and nothing but the
> splash screen is visible.
Hi Fred,
I believe #3 is most likely the dominant factor. I don't know if I can
recall the whole history of development, but I think it started out with the
introduction of the threaded tile loader to reduce pauses when new tiles
needed to be loaded. Plib was not multithreaded and neither is opengl so we
could fake it mostly and load all the terrain data and build the scene
graph, but model loading (which can trigger texture loading which triggers
opengl calls) could not be moved outside the render thread. So any models
that needed to be loaded where pushed onto a queue and one (or maybe a few?)
were loaded each rendered frame.
At the time, FlightGear started running as soon as the local tile was loaded
(so that the local terrain elevation could be determined and so that the
aircraft could be properly ground trimmed.) However, this meant that you
saw the remaining elements of the scene loading and popping into view and
often this led to really stuttery frame rates until everything was loaded.
So the solution was to keep the splash screen drawn and hide the main scene
until after all these initial loads have taken place, but as you have
pointed out, these are interleaved, one at a time between scene draws which
are never actually shown. Also, the FDM is running during this time, even
though nothing is being shown to the user (that means the plane could be
falling or bouncing or rolling down the runway before the view comes up.)
It might make sense to come up with a flag somewhere and just flush the load
queue entirely in one shot at startup rather than hide the outside world
with the splash screen? What we've grown into right now clearly is
inefficient.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
