Thread: Re: AW: [Dynapi-Dev] DynAPI build, Splitting files (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Ahh.. but when you're running those If statements through a loop that
creates several hundred layers, there is a HUGE difference in
performance.... and generation of layers in IE should be changed... as there
is a huge performance hit when the createLayer method is called for all
layers at once... if DOM methods are used, for IE specific, then the layers
can be created as they are instanciated, and when they are to actually be
displayed in the browser, simply use DOM methods to move the node into the
visible browser buffer. It would be like an off-screen buffer holding all
code and properties that would be quickly added in 2 method calls.

IE has a built-in XML parser with DOM methods which can be the back-end
buffer, and should be able to transfer node from the XML tree to the browser
DOM tree. All the property setting would be done in the back-end native
code, thus making it faster.

Who knows DOM? (oh... to create an XML object in IE5+, simply
document.writeln('<XML id="XMLObj"></XML> ');  Then to access:
document.all.XMLObj  references the Document object of the XML DOM tree.

----- Original Message -----
From: "Pascal Bestebroer" <pa...@dy...>
To: <dyn...@li...>
Sent: Sunday, December 10, 2000 12:25 PM
Subject: RE: AW: [Dynapi-Dev] DynAPI build, Splitting files

> This is a repost (previous one seems to have gotten lost :)
>
> Once you split up parts of the API for every browser (that could
eventually
> include Opera, and other flavours) it means that people will start
focusing
> on a single browser because that's the browser they'll be using.  Ofcourse
> this is already being done on a smaller scale (Dan's main focus seems to
be
> Netscape, and my focus is more IE5+) but at this point because of the code
> being one , we know that what ever we do should also work Netscape.. once
> you split things up I think this "awareness" will disappear and people
will
> just enhance the code for that single browser and let someone else worry
> about the other browsers files.
>
> "All this is done only to define two basic paisr of vars. Terrible. And
> impossible just to skip the nn stuff, becoause it's not clear, what refers
> to nn but only what is not for ie. I have to go through it and to
> learn the"
>
> that's correct, just two basic pairs of vars, so you want to split all
code
> up for simple things like these? And the fact that you have to go thru it
> and learn the differences is exactly my point, if you have the chance to
> only do your coding for IE, you will forget about NS and this might cause
> you to implement things in IE that are not possible in NS.  Ofcourse this
> means we're holding back one browser because of the incompatibilities with
> the other, but that's the problem with cross-browser coding, and if you
need
> that extra functionality you should added it in your own code, not in the
> general API.
>
> The problem with speed that everybody talks about is not such a big issue,
> we're not developing for 386 or 486 machines anymore, Pentium machines
don't
> take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF
> statements are only called at initialisation and when changing styles, the
> main bottle-neck is not the IF statement but the time it takes browsers to
> redo the style sheet (and rerender things).  This is just a browser
problem,
> not a code problem.
>
> And ofcourse size isn't such a big issue neither, seeing that most of the
> differences (I know, not all) are done on single lines as you pointed out:
>
> is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
>
> this will only be a few bytes difference once you split it up:
>
> e.x+document.body.scrollLeft
>
> so maybe you save some bytes with the split but you have to include all
> files multiple times and maintain all files multiple times for your site
to
> look good on all browsers.
>
>
> apologies for the long post :)
>
> cya,
>
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev