Well we just can't win them all. Ignoring the ._updateValues() function is possible by setting a _ignoreUpdates propery on the dynlayer. This however makes things more complicated.
The use of a this.css() was discussed some time ago. It was said that getElm() and getCss() functions help to improve the the speed of dynlayers by 25%. This will however brake many things :( But since we're in the alpha stage I think it's a great time to start braking things (ain't that right Doug? - just kidding). Doug wants to start converting the widgets, so I told him that the API is pretty much stable, but I think we should really take a serious look at this situation. Should we go the route of implementing getCss() and getElm() functions? These would prevent the need to loop through dynlayers in an effort to assign elm's and css's. -- Raymond Irving --- Benoit Marchant <[EMAIL PROTECTED]> wrote: > Here's my findings: > > speedtest.dynlayer-basic.inline.html: same code as > speedtest.dynlayer-basic.html, except that the loop > does call setID to > set the inline property. I timed until all dynlayers > are initialized. > There's not much difference, and some time inline is > a bit slower. > Since you have to loop the same amount of layers to > create them anyway. > This is a little irrelevant in fact. The huge win > with inline layers is > that from a user point of view, everything is > visible right away. > I played a little with the inline code to see what > was going on, there > was a serious gain by not doing > > DynLayer._updateValues(this) in > DynLayer.prototype._createInline. > Accessing the values in dlyr.elm and dlyr.elm.style > takes some times. > Now if you think about it, server side, you know > these values, so when > you create the layer, you can just create it with > its values. > > For example, in > speedtest.dynlayer-basic.inline.html, I could do > > lyr=new DynLayer(null,x,y,20,20,'yellow');// Then > passing the same > values as the one I would findout by doing > DynLayer._updateValue, > instead of doing > > lyr=new DynLayer(); > and rely on _updateValue to fill the blanks. > > The other thing that we could do might be even > better. Why pay the > price of initializing all of that when it could be > done lazily ? If you > were to use aLayer.css() instead of aLayer.css, then > for inline layers, > we could set this.css = something just if someone > asks for it. The same > is true for all the values set in > DynLayer._updateValue. > > As a side note, is it necessary to call > captureMouseEvents() on a > dynlayer that has no listener ? > in DynLayer._assignElement, there's a test I don't > understand: > > if (dlyr._hasMouseEvents) > dlyr.captureMouseEvents(); > and captureMouseEvents is the only place where > this._hasMouseEvents is > set to true; ???? > > > Feedback ? > > Benoit > __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[EMAIL PROTECTED]/
