20,741
edits
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 }}}} |