Resource Tracking for FlightGear: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
 
Line 24: Line 24:
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2  where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode. This simplified startup mode results in roughly ~120 MB of savings in RAM. ]]
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2  where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode. This simplified startup mode results in roughly ~120 MB of savings in RAM. ]]
-->
-->
{{FGCquote
|1= we DO load all textures for all effects right now - this is bug #610, which I was recently reminded about, and am doing some hacking on. This is certainly not helping our performance or memory footprint on lower-end machines since the various textures for highest-quality effects (the water depth shader, bump maps, reflection maps) are all being loaded. It’s also making startup / reset slower.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/32173241/
  | title  = <nowiki>Re: [Flightgear-devel] Towards better scenery rendering</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Apr 1st, 2014
  }}
}}


{{FGCquote|1= we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. We have two classes for smart, referencecounted pointers, <code>osg::ref_ptr</code> and <code>SGSharedPtr</code> which should be used for all long-lived, shared objects. |2= {{cite web  | url    = http://forum.flightgear.org/viewtopic.php?p=214289#p214289  | title  = <nowiki>Re: How can I retire from the forum?</nowiki>  | author = <nowiki>Tim Moore</nowiki>  | date  = Sat, 19 Jan 2008 02:40:21 -0800  }}}}
{{FGCquote|1= we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. We have two classes for smart, referencecounted pointers, <code>osg::ref_ptr</code> and <code>SGSharedPtr</code> which should be used for all long-lived, shared objects. |2= {{cite web  | url    = http://forum.flightgear.org/viewtopic.php?p=214289#p214289  | title  = <nowiki>Re: How can I retire from the forum?</nowiki>  | author = <nowiki>Tim Moore</nowiki>  | date  = Sat, 19 Jan 2008 02:40:21 -0800  }}}}

Navigation menu