Re: [Dynapi-Dev] DynAPI current things

[Robert R. <rra...@ya...>]

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/