It was for a federal government contract. We needed to build a tree containing all of the government codes -- represented by an icon, title and a checkbox -- for the different government agencies. This allowed a clerk to perform a easily select a search criteria for videos within the archives for the selected codes within each agency. The icon images were pre-compiled into the application.
It was built on DHTML and even ran on IE6. Surprisingly enough, the performance on IE6 was competitive with the other browsers. Norman Klein Author: Laszlo in Action On Fri, Mar 12, 2010 at 8:53 AM, <[email protected]> wrote: > What the hell did you need 2300 nodes for??? But good to know!! > > Cheers, > Raju > > ------------------------ > ------------------------------ > *From: * Norman Klein <[email protected]> > *Date: *Fri, 12 Mar 2010 08:10:04 -0800 > *To: *Rami Ojares<[email protected]>; <[email protected]> > *Subject: *Re: [Laszlo-user] Mouse performance > > > Once upon a time, I used opttree (actually checktree that is based on > opttree) to implement a tree that contained approximately 2300 nodes and > didn't encounter any mouse degradation issues. > > You might want to take a look at the opttree code and how they implemented > things. > > Norman Klein > Author: Laszlo in Action > > On Fri, Mar 12, 2010 at 3:34 AM, Rami Ojares <[email protected]>wrote: > >> Allright I tried the following handler for my TreeNodes >> >> <handler name="onvisible" args="visible"><![CDATA[ >> >> if (!this.inited) return; >> >> //var count = 0; >> >> var allSubnodes = GET_ALL_SUBNODES(this.subnodes); >> if (allSubnodes==null) return; >> >> for(var i=0; i<allSubnodes.length; i++) { >> >> var delegates = allSubnodes[i].__LZdelegates; >> if (delegates == null) continue; >> >> for(var j=0; j<delegates.length; j++) { >> var del = delegates[j]; >> //count++; >> if (visible) del.enable(); >> else del.disable(); >> } >> } >> >> //Debug.debug("%w delegates %w", count, visible ? "enabled" : >> "disabled"); >> ]]></handler> >> >> No effect. >> The unregistering MIGHT have had some effect but I am not sure anymore. >> >> The only thing I have really found to have an impact on the performance is >> destroying the objects. >> But I discarded the creation/destroying strategy long time ago because it >> was way too inefficient. >> More and more I have been building object pools so I would not have to >> create objects so often. >> >> Can you Tucker say does disabling/enabling of delegates have any >> performance gain? >> >> So the lesson seems to be this: >> "If you have a lot of views/objects your mouse performance starts to >> choke." >> Solution: >> "Try not to have a lot of objects." >> >> The only way out I can see now is to start stripping off features of my >> TreeNodes. >> >> - rami >> >> On 11.3.2010 19:56, P T Withington wrote: >> >>> What platform are you compiling to? I recall there is a Flash player bug >>> that bit G.ho.st that had something like what you describe. >>> >>> But also, I have to wonder if something with 100's of sub-menus doesn't >>> need a different approach. I wonder how a human navigates such a large >>> space. >>> >>> On Mar 10, 2010, at 17:48, Rami Ojares <[email protected]> wrote: >>> >>> Hi, >>>> >>>> I have a tree structure (branches and leaves). >>>> All of them react to various mouse events (mouseover, mousedown, >>>> mousetrackover etc.) >>>> I have implemented a mechanism where I initially load/construct only the >>>> first level of nodes. >>>> Everything works fine and with good performance. >>>> When I keep opening branches (some of which have over hundred subnodes) >>>> the mouse event performance starts to choke. >>>> >>>> So I thought that whenever a node is not visible I disable all the >>>> delegates handling the mouse events. >>>> No effect. >>>> Then I tried unregistering the delegates when the node is not visible. >>>> No effect. >>>> Then I tried to set the clickable attribute to false for all the views >>>> that react to mouse events. >>>> No effect. >>>> >>>> Any suggestions? >>>> >>>> - rami >>>> >>> >> >
