Update DesignPrinciplesAndPhilosophy.md

Fixed typos

docs/Design/DesignPrinciplesAndPhilosophy.md

@@ -6,9 +6,9 @@ This document introduces the design principles/philosophy of the project lead Ro
 
 First lets break down the opening phrase, *"Successful Software Lives For Ever"*, one I coined for a training course over a decade ago:
 
-* What is *"Success Software"* : Software that is useful and reliable enough for developers and/or users to adopt it as a part of their work or personal lives and rely upon it to live for as long as they need it.
+* What is *"Successful Software"* : Software that is useful and reliable enough for developers and/or users to adopt it as a part of their work or personal lives and rely upon it to live for as long as they need it.
 
-* How long is *"For Ever"* : Long enough that time during maintenance and evolution is significantly longer than initial time to develop the first stable release. Software that is unreliable, hard to maintain and evolve becomes unsustainable in the long term, it looses it's relevance because of it and fails. Success demands good design, implementation and responsive curation over many years.
+* How long is *"For Ever"* : Long enough that time during maintenance and evolution is significantly longer than initial time to develop the first stable release. Software that is unreliable, hard to maintain and evolve becomes unsustainable in the long term, it loses it's relevance because of it and fails. Success demands good design, implementation and responsive curation over many years.
 
 
 For the OpenSceneGraph project what made it a success was it achieved *performance* levels that competed well with the best proprietary and open source scene graphs, and was well designed enough to help developers be *Productive* over long term application development and deployment. Responsive of contributors to support the community has also been crucial for the OpenSceneGraph remaining relevant to real-time graphics application developers for nearly two decades.
@@ -51,11 +51,12 @@ The principles used as a guide to achieving efficiency include:
 
 An example of minimizing footprint, non essential conditions and data storage has already impacted the design and implementation can be seen in minimizing the size of the core [vsg::Object](../../include/vsg/core/Object.h) that is backbone of the scene graph by moving all optional data out into an optional [vsg::Auxiliary](../../include/vsg/core/Auxiliary.h) class.  This change reduces the size of vsg::Object to 24 bytes, compared to the OpenSceneGraph's osg::Object class that is 72 bytes.  The vsg::Node class adds no extra data members overhead so remains at 24 bytes, while the OpenSceneGraph's osg::Node class footprint is 20 bytes.  These memory footprint reductions are carried over to all objects in the scene graph.
 
-Scene graphs are fundamentally a graph of objects connected by pointers between those objects.  The size of those objects is inextricably connected to the size of pointers. C++11 onwards provides the std::shared_ptr<> which on 64-bit systems has a size of 16 bytes, while the VSG's intrusive reference counting enables the vsg::ref_ptr<> to have a size of 8 bytes.  In experiments with creation of a quad tree scene graph using std::shared_ptr<> vs vsg:::ref_ptr<>, the shared_ptr<> results in a 75% more memory used overall, and 65% slower traversal speeds. This significant difference illustrates that one should not assume that C++ core features are always the most efficient tool.
+Scene graphs are fundamentally a graph of objects connected by pointers between those objects.  The size of those objects is inextricably connected to the size of pointers. C++11 onwards provides the std::shared_ptr<> which on 64-bit systems has a size of 16 bytes, while the VSG's intrusive reference counting enables the vsg::ref_ptr<> to have a size of 8 bytes.  In experiments with creation of a quad tree scene graph using std::shared_ptr<> vs vsg::ref_ptr<>, the shared_ptr<> results in a 75% more memory used overall, and 65% slower traversal speeds. This significant difference illustrates that one should not assume that C++ core features are always the most efficient tool.
 
 Traversals of a scene graph and dispatch graphs are the main operations that a scene graph undertakes each frame, cache misses and lowering the cycle overhead per object visited is key to reducing traversal times.  The memory footprint reduction immediately reduces the number of page faults that occur and avoiding non essential conditionals provides a second improvement as it reduces number of cycles required per object visited.
 
-The way that avoiding non essential conditionals has been addressed is to drop the NodeMask and TraversalMode parameters that are found in the OpenSceneGraph's osg::Node and osg::NodeVisitor respectively.  When NodeMask functionality is required in a scene graph the task will fall to a MaskGroup that will have a local mask and undertake the conditional during traversals that is required, so that only scene graphs that require a mask will pay the penalty for it.  Decision of what type of traversal to undertake is also moved to the Visitor subclass rather than the Visitor base class.  Finally the NodePath that is automatically accumulated by the OpenSceneGraph's NodeVisitor is also dispensed with, if Visitor implementation require this functionality then they are left to implement it.
+The way that avoiding non essential conditionals has been addressed is to drop the NodeMask and TraversalMode parameters that are found in the OpenSceneGraph's osg
+Node and osg::NodeVisitor respectively.  When NodeMask functionality is required in a scene graph the task will fall to a MaskGroup that will have a local mask and undertake the conditional during traversals that is required, so that only scene graphs that require a mask will pay the penalty for it.  Decision of what type of traversal to undertake is also moved to the Visitor subclass rather than the Visitor base class.  Finally the NodePath that is automatically accumulated by the OpenSceneGraph's NodeVisitor is also dispensed with, if Visitor implementation require this functionality then they are left to implement it.
 
 To test the effectiveness of these design differences a test program, vsgroups (found in vsgFrameworks project) was used. The results of these seemingly small design changes over the OpenSceneGraph have a dramatic improvement in performance.