dynapi-dev

RE: [Dynapi-Dev] getParent()

[Pascal <pb...@oi...>]

as far as I know those two methods are removed (they were hardly never used)

and seeing as the DynLayer is so "bloated" already I don't think adding
methods like this will aid in the optimisation of the DynLayer, and the
parent property also refers to the parent. (there are a few other methods
that should be possible to be removed, or atleast simplified).


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard Bennett
> Verzonden: dinsdag 20 februari 2001 15:33
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] getParent()
>
>
> Isn't this
> myDynLayer.getParentComponent() ?
> myDynLayer.setParentComponent(blah) ?
>
> Cheers,
> Richard Bennett
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot
> of DynAPI2)
> Find the DynAPI faq here:
> http://sourceforge.net/docman/display_doc.php?docid=656&group_id=5757
> Browse the mailinglist here:
> http://www.mail-archive.com/index.php3?hunt=dynapi
>
>
> ----- Original Message -----
> From: "Alex Chong" <c....@mu...>
> To: <dyn...@li...>
> Sent: Tuesday, February 27, 2001 9:55 AM
> Subject: [Dynapi-Dev] getParent()
>
>
> > Hi,
> >
> > Currently, the parent of a DynLayer is accessed using
> > myDynLayer.parent.  I suggest in future Dynapi release, instead of
> > accessing the parent directly, we use a getter function: i.e.
> > myDynLayer.getParent().
> >
> > This brings alot of convenience to the widget development.
> Sometimes, a
> > widget may want other to 'believe' that its parent is some
> other layer
> > instead of its real parent.
> >
> > Alex Chong
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > ____________________________________________________________
> > Get your free domain name and domain-based e-mail from
> > Namezero.com. New!  Namezero Plus domains now available.
> > Find out more at: http://www.namezero.com
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] getParent()

[Eytan H. <ey...@tr...>]

That is not what slows down the creation of layers.
It's the problem with the addChild chain that I told you. I can make the
Canvas have all these methods if you like and the time will be about the
same.
8an

RE: [Dynapi-Dev] getParent()

[Pascal B. <pa...@dy...>]

duh!  (sorry, just being annoying again :)
not all optimisation is for speed!
adding stuff to the DynLayer object will make larger memory foot prints, and
in most cases it's unneeded.

Adding these convenience methods was a nice idea at first.. but they are all
adding up to the memory footprint of a single DynLayer.
Something "we" should also take under consideration, not just your speed
issues.

But getting back on that subject again, I've been doing some optimising to
the DynLayer, and got it down from 42 secs to 34secs with 500 layers (on a
600mhz machine).. for now only did this on Dynacore, but most stuff can be
done on the official as well.

I'm still no fan of your canvas ideas, it would require all users to change
there code that is using DynAPI now! In my opinion once you have all
dynlayer functionality in, your canvas will be slower then it is now
(regardless of your addchild ideas) and might actually get as slow as
dynlayer (Seeing that most code is still the same).

Also, you keep mentioning that the  object  passing between methods is
what's slowing down stuff.. then how are you going to add a child to the
parent? aren't you passing the parent object then?

If you would compare the speed of this current DynLayer with the one we had
a year ago, you would also see big speed differences.. but eventually you
need extra functionality and this is the fault with the current dynapi: it
needs a big clean-up, not a complete change in code and usage. Everything
got pasted onto it, without doing any optimising.. in the createelement
there are a few if (is.xx) statements, that can be combined into one, and
more of these optimisations.



Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan Heidingsfeld
> Verzonden: dinsdag 20 februari 2001 16:54
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] getParent()
>
>
> That is not what slows down the creation of layers.
> It's the problem with the addChild chain that I told you. I can make the
> Canvas have all these methods if you like and the time will be about the
> same.
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] getParent()(Should be throwing rocks at 8an)

[Eytan H. <ey...@tr...>]

Pascal,
A few issues:
1. Memory footprints of the actual objects (DynLayer) and not the elements
should be able to be released (gotta check that out).
2. Backwards compatibility is the word (or phrase). We add a method (listed
as deprecated) called addChild which sets the child's parent to self and
creates it something like this:
DynLayer.prototype.addChild = function(chld){
   chld.owner = this;
   chld.create();
}
That's all you need!!
3. First of all about if statements they take no time (basically) they are
not what is slowing you down. I will explain the difference between my
passing of objects and yours. Since JS has no pointers JS automatically
manages them. That means that an object is created once and then can be
passed but is passed as a pointer (anyone have tech stuff about this??).
What I do is as such
new Canvas(owner)
this.owner = owner;

JS interprets this as such:
1. Take pointer of owner
2. Replace the pointer of this.owner to the pointer of owner
3. Only once the object is passed and it is passed as a pointer. JS doesn't
need to call anything currently from this object just set up a pointer to
it.

DynLayer way:
new DynLayer()
addChild
Create element.
Pass DynLayer and Element to static function
Static function must take both objects and take the DynLayer as an object
and set up this.elm to point to Element

As you can see (here and in the tests) my way is more effective. It is also
logically more effective because each layer has his own responsibility to
create himself and doesn't have to delegate this responsibility to his
parent.

8an

RE: [Dynapi-Dev] getParent()(Should be throwing rocks at 8an)

[Pascal B. <pa...@dy...>]

(First: sorry people for this long post.. but this is fun isn't it :)

Here's the new createElement of my Dynacore code, I removed all
functionality not available in your code, and then used the timing test you
posted a few days ago..

I personally don't believe in these tests  (running it a few times will give
different numbers.. so browsers are not very stable on handling stuff) but
please run the test your self (not sure if the code below works in current
dynapi). I used a test with 500 layers.. your code 2100ms, my code 1980ms..
so I'd say we break even.

As you can see I had to take out ALOT of functionality not available in your
code (recycle array, setting up the images for event triggering, invoking
events on all child layers, setting bgimage + fixing the IE5.5 event bug,
the getContentWidth/height checks and calls)

Also I took another look at your nested test.. that's not valid. When people
use the code (or widgets) usually the child layers are added to the parent
layer, BEFORE the parent layer is added to the document (created). This is
the beauty and power of the precreation.. all those child layers will then
not be created but written into the parent (skipping ALOT of overhead by not
having to call the createelement and having to be inserted into the
document, or have every CSS style be set seperatly)


I think your code could also do with a little optimisation (seeing that your
using the dynapi code for a large part) but I don't think the differences in
speed (between dynlayer and canvase) would be that big.. once I get this
optimising round done and checked, I'll try to work these things into the
official DynAPI.

I AM very interested in any documents to back up your ideas about how the
objects are passed..but for now you still don't have me convinced there's a
noticeable difference to be gained ;-)


If you want I can post the current Dynacore "snapshot", but here's my
current createElement code (people this is NOT a patch)

DynLayer.prototype.createElement=function() {
//	if (this.created||!this.parent||this.elm!=null) return
	if (this.parent.isDocument) this.dyndoc=this.parent
    	else this.dyndoc=this.parent.dyndoc

	if (is.ns4) {
//		var recycled=this.parent.doc.recycled
//		if (recycled && recycled.length>0) {
//	        	this.elm=recycled[0]
//			DynAPI.removeFromArray(recycled,recycled[0])
//		} else {
			this.elm=new Layer(this.w,this.parent.elm)
			this.elm.captureEvents(Event.LOAD)
			this.elm.onload=function() {}
//		}
		this.css=elm
		this.doc=elm.document
		this.doc.lyrobj=this
//		for (i in this.doc.images) this.doc.images[i].lyrobj=this
	} else var
parentElement=(this.parent.isLayer)?this.parent.elm:this.parent.doc.body
	if (is.ie4) {
		var code='<DIV id="'+this.id+'" style="position:absolute; left:0px;
top:0px; width:'+this.w+'px;"></DIV>'
		parentElement.insertAdjacentHTML("beforeEnd", code)
		this.elm=parentElement.children[parentElement.children.length-1]
		this.css=this.elm.style
		this.doc=this.parent.doc
//		for (i in this.elm.all.tags("img"))
this.elm.all.tags("img")[i].lyrobj=this
	} else if (is.ie5 || is.ns5) {
		parentElement.appendChild(this.elm=this.dyndoc.doc.createElement("DIV"))
		this.elm.style.position="absolute"
		this.elm.id=this.id
		this.css=this.elm.style
		this.doc=this.parent.doc
//		if (is.ns5) for (i in this.doc.images)
this.doc.images[i].lyrobj=this.elm
//		if (is.ie5) for (i in this.elm.all.tags("img"))
this.elm.all.tags("img")[i].lyrobj=this
	}
	this.elm.lyrobj=this

//	for (var i=0; i<this.children.length; i++)
this.children[i].invokeEvent('precreate')
//	this.invokeEvent('precreate')

	this.setSize(this.w,this.h,false)
	if (is.ns4) {
		this.elm.moveTo(this.x,this.y)
		this.doc.write(this.getInnerHTML())
		this.doc.close()
	} else {
		this.css.left=this.x
		this.css.top=this.y
		this.setHTML(this.html) //this.getInnerHTML())
	}
	if (this.bgColor!=null) this.setBgColor(this.bgColor)
//	if (this.bgImage!=null) this.setBgImage(this.bgImage)
//	else if (is.ie55 && this.html==null) this.setBgImage('javascript:null')
//	if (this.clip!=null) this.setClip(this.clip)

//	this.css.zIndex=this.z
	this.css.visibility=this.visible? "inherit" : (is.ns4?"hide":"hidden")

//	this.assignChildren()

//	if (this.html!=null) {
//		if (this.w==null && this.getContentWidth()>0)
this.setWidth(this.getContentWidth(), false)
//		if (this.h==null && this.getContentHeight()>0)
this.setHeight(this.getContentHeight(), false)
//	}

//	if (this.hasEventListeners) {
		this.captureMouseEvents()
//		var elm=this.elm
//		if (is.ns4) elm.captureEvents(Event.MOUSEDOWN | Event.MOUSEUP |
Event.CLICK | Event.DBLCLICK)
//
elm.onmousemove=elm.onmousedown=elm.onmouseup=elm.onmouseover=elm.onmouseout
=elm.onclick=elm.ondblclick=DynObject.prototype.EventMethod
//		if (is.ie5) elm.oncontextmenu=function(){return false}
//	}

//	this.created=true
//	this.invokeEvent("resize")
//	this.invokeEvent('create')
}


Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

Re: [Dynapi-Dev] getParent()

[Jordi - I. - M. <jmi...@or...>]

Absolutely. When I talk 'rewriting things' I'm not saying we should rebuild the
code but rewrite what we already have. Now we know all the "ifs" that are goiung
to be there, so we can organize the internal code in a better way.

Pascal Bestebroer wrote:

> duh!  (sorry, just being annoying again :)
> not all optimisation is for speed!
> adding stuff to the DynLayer object will make larger memory foot prints, and
> in most cases it's unneeded.
>
> Adding these convenience methods was a nice idea at first.. but they are all
> adding up to the memory footprint of a single DynLayer.
> Something "we" should also take under consideration, not just your speed
> issues.
>
> But getting back on that subject again, I've been doing some optimising to
> the DynLayer, and got it down from 42 secs to 34secs with 500 layers (on a
> 600mhz machine).. for now only did this on Dynacore, but most stuff can be
> done on the official as well.
>
> I'm still no fan of your canvas ideas, it would require all users to change
> there code that is using DynAPI now! In my opinion once you have all
> dynlayer functionality in, your canvas will be slower then it is now
> (regardless of your addchild ideas) and might actually get as slow as
> dynlayer (Seeing that most code is still the same).
>
> Also, you keep mentioning that the  object  passing between methods is
> what's slowing down stuff.. then how are you going to add a child to the
> parent? aren't you passing the parent object then?
>
> If you would compare the speed of this current DynLayer with the one we had
> a year ago, you would also see big speed differences.. but eventually you
> need extra functionality and this is the fault with the current dynapi: it
> needs a big clean-up, not a complete change in code and usage. Everything
> got pasted onto it, without doing any optimising.. in the createelement
> there are a few if (is.xx) statements, that can be combined into one, and
> more of these optimisations.
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Eytan Heidingsfeld
> > Verzonden: dinsdag 20 februari 2001 16:54
> > Aan: dyn...@li...
> > Onderwerp: RE: [Dynapi-Dev] getParent()
> >
> >
> > That is not what slows down the creation of layers.
> > It's the problem with the addChild chain that I told you. I can make the
> > Canvas have all these methods if you like and the time will be about the
> > same.
> > 8an
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev