From: Doug M. <do...@cr...> - 2001-02-22 16:46:17
|
would it make things any bigger if each layer has a this.rootDoc property? This would allow you to avoid having to "search all the way to the top of the chain" no? ----- Original Message ----- From: "Robert Rainwater" <rra...@ya...> To: "DynAPI Development List" <dyn...@li...> Sent: Thursday, February 22, 2001 8:41 AM Subject: Re: [Dynapi-Dev] DynAPI current things > > One of the things that can slow down layer creation when you have lots > of children it the addChildID. The reason for this method is because > it has to search all the way to the top of the chain to find out who > is dyndoc is. If we can find a way to set the dyndoc during the > addChild is would speed up things a lot. > > -- > // Robert Rainwater > > On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI current things": > > > Here's a list of thing I want to change in the current DynAPI code. I'm not > > searching for long discussions here, but I want to hear some (short) > > opinions and mainly from the people actually involved in the development. > > > > * Do some speed optimisations > > Mainly changes to the createElement as I did on dynacore as test, and seem > > to speed things up very nicely, without breaking code. also some checking > > on why the latest release is so much slower (have to test this for myself > > though because haven't seen it myself, just from others) > > > * DOM defaults > > All "if (is.xx) else..." statements should be changed so that the NS6 code > > is always the default (basically, no NS6 check should be left in the code). > > This should prove first steps towards support for true DOM compliant > > browsers (they should then work for a large part) > > > * Better object arrangement > > Split event code up for mouseevents/normalevent-invoking (like Michael did). > > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument as > > did in dynacore. Should prove to be easier to "get into the code" with > > DynObject handling ALL parent/child relations, and DynLayer only doing that > > what it should: dynamic layers handling. > > > * addChild() change > > AddChild currently supports multiple children as parameter at once.. no body > > uses it, no body should. Removing support for that should also give a slight > > speed increase (the child is already supplied as parameter to the function, > > so I think it will be seen as a local variable) no need to walk thru an > > array, which is an extra loop not needed. the support for multiple children > > adding at once, could be created by users them self..not very hard to do. > > > * DynDocuments adding to DynAPI > > All DynDocuments should be child objects of the DynAPI object, this way you > > get a true DynAPI tree which can be used to access ANY object created by the > > DynAPI.. Only code that needs to be changed for this by users is code that > > used frames (the dyndocument generated should become > > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > > memory-cleaning needed. > > > > I'm planning on doing the first two points this weekend and possible a few > > others.. the only thing that will be time consuming is the "Better object > > arrangement" (means ALOT of testing to see if nothing got broken) > > > Any, helpful, takes on these ideas are welcome.. but please don't make this > > a long discussion thread.. if some one doesn't like it we can discuss it, > > but otherwise I'll start on it this weekend (unless some one else does it > > before that :) > > > > > Pascal Bestebroer (pb...@oi...) > > Software ontwikkelaar > > Oberon Informatiesystemen b.v. > > http://www.oibv.com > > > > _______________________________________________ > > Dynapi-Dev mailing list > > Dyn...@li... > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > > > ---------------------- > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ > DynAPI Homepage: http://dynapi.sourceforge.net/ > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > --- Outgoing mail is certified Virus Free by AVG Free Edition Download at: http://www.grisoft.com/html/us_index.cfm Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 |