Change:	38934
Change:	38934

User:	jgrandy

Description:
	Summary:Optimize Explorer nav bar to make it launch much faster
	
	Bugs Fixed:LPP-1573
	
	Technical Reviewer: max (pending)
	QA Reviewer: frisco (pending)
	Doc Reviewer: jsundman (pending)
	
	Documentation:See details for an undocumented feature of basetree. Also the
	sample code for basetree in the Reference is not optimal -- it shouldn't
	declare a recursive subview tree, but let the basetree allocate subtrees
	dynamically. This is filed as LPP-1574.
	
	Details:I made three discrete types of optimizations to reduce the launch
	time of the Laszlo Explorer nav bar by at least 90%.
	
	First, I removed initialization overhead by removing $path-constrained
	attributes and computing the data attributes when needed (which was mostly
	when the tree item was opened, rather than at initialization time).
	
	Second, I drastically reduced the subnode count of the custom tree class
	being used. I did this by replacing two states that swapped out a view and a
	text view with different text sizes and view widths with code that directly
	modified a single view/text pair when necessary. I also removed two
	animator groups from the subnode declaration by hoisting them into classes
	and instantiating the classes only when the animator groups were first used.
	
	These two were collectively good for only about 8%, even though the subview
	count was substantially reduced.
	
	The reason for this is that 200+ instances of the menubutton class (subclass
	of basetree used in the navbar) were being built. This is odd because there
	are only 130 or so items in the navbar data set. And it's wasteful because
	only nine menubutton instances are visible at startup (seven at top level
	plus two within the initially opened toplevel item).
	
	The 130/200 discrepancy is because of how the tree structure is declared in
	this app:
	
	<navbutton width="160" datapath="*" level="0">
	  <navbutton width="160" datapath="*" level="1">
	    <navbutton width="160" datapath="*" level="2">
	      <navbutton width="160" datapath="*" level="3">
	    </navbutton>
	  </navbutton>
	</navbutton
	
	This means that the code allocates a perfectly balanced tree of depth 4
	even if there aren't four levels of nesting under each item.
	
	So this accounts for the extra 70 or so navbuttons allocated.
	
	(As a side note, basetree already supports dynamic allocation at init time
	of all nodes fitting the dataset. Use of this feature would eliminate the
	extra allocations at startup time.)
	
	But then I realized there isn't really any reason to allocate more than
	the seven toplevel items at init time, since subitems can be allocated
	as necessary when items are opened.
	
	This change turned out to be relatively easy. Basically I modified the
	code to instantiate a 'seed' subitem on first open, and then the rest of
	the open code is deferred until either (1) that seed item is initialized
	(if it isn't replicated), or (2) all clones are initialized (in the 
	replicated case).
	
	So instead of 200 menubutton instance allocations, we're down to nine
	(seven for the top items, plus two for the subitems of the item that is
	open at launch.) This reduces launch time for the whole Laszlo Explorer
	from seventeen seconds to four seconds on my machine. I think the total
	reduction for just the navbar is over 90%.
	
	   The change to dynamically allocate subitems upon open rather than at init
	   time could be applied to basetree and then shared by all users of that
	   class. I will make that change as a separate checkin since it is likely to
	   be too big to include into our upcoming 3.2 release. I'll also look into
	   making this same optimization to the reference index.
	
	Tests:Ran Laszlo Explorer

git-svn-id: d62bde4b5aa582fdf07c8d403e53e0399a7ed285@169 fa20e4f9-1d0a-0410-b5f3-dc9c16b8b17c

mcarlson/openlaszlo,mcarlson/openlaszlo,mcarlson/openlaszlo,mcarlson/openlaszlo,mcarlson/openlaszlo,mcarlson/openlaszlo,mcarlson/openlaszlo