Thanks everyone. It seems like the best way for us is to change the UI design so that it will render only 10 or 15 nodes at a time. Tree Table is probably a good solution to this.
-----Original Message----- From: Andrew Robinson [mailto:[EMAIL PROTECTED] Sent: Sunday, October 26, 2008 3:13 PM To: MyFaces Discussion Subject: Re: Trinidad Large Tree It may not be javascript either. The Trinidad Tree is rendered using HTML tables which are notoriously slow with IE (especially IE 6). In fact TD inner* dimension calculations are many times slower than any other HTML element. So this could easy be a problem with IE's slow rendering issue. One approach is for you to change your tree model so that it creates "next" and "previous" links in large nodes (if you have many direct children). Try to keep the number of visible child nodes to under 15 if you can help it. On Sun, Oct 26, 2008 at 8:17 AM, Jan-Kees van Andel <[EMAIL PROTECTED]> wrote: > It's a fact that IE is much slower than the others when dealing with large > DOM trees, but there are ways to make IE happy. For example, not using > document.getElementById, but a custom function. > > For example, when you are searching for an ID inside a parent container, > document.getElementById is slow, since it searches through the whole > document. > > In those cases, the following snippet can be much faster. > function findElementById(root, id, tagname) { > if (!tagname) tagname = '*'; > var s = root.getElementsByTagName(tagname), i = s.length; > while (i--) { > if (s[i].id == id) > return s[i]; > } > return null; > } > > root is the root element where you are searching in, id is the id you are > looking for and tagname can be used for optimization when you know what tag > to look for. > > There are all kind of optimizations that can be done to make ID happy. The > only problem is that the Trinidad component authors need to make this > change, so you have to wait for a release with this change... If you don't > have the time, I suggest you look for an alternative. > > But again, IE can be fast, depending on the JavaScript. > > Regards, > Jan-Kees > > > 2008/10/26 Simon Kitching <[EMAIL PROTECTED]> >> >> One thing I discovered recently is that Firefox handles large numbers of >> html components better than IE. I had to debug a jsp page that would run >> slower & slower under IE, but appeared to work under firefox. The >> problem turned out to be a bug that caused an exponential increase in >> the number of copies of a particular hidden input field in the page; IE >> had problems when it got into the thousands, while firefox only showed >> symptoms when the number of copies was significantly higher. >> >> So my guess would be that this page is just too complex for IE and that >> you need to redesign your page to avoid having so many html tags in it. >> >> Regards, >> Simon >> >> On Sat, 2008-10-25 at 21:15 +0200, Burghard Britzke wrote: >> > may be it is the javascript code used by the tree component which >> > screw up ie? >> > >> > burghard. >> > >> > Am 25.10.2008 um 15:30 schrieb Matthias Wessendorf: >> > >> > > Are you saying the issue is the JavaScript in IE ? >> > > >> > > -Matthias >> > > >> > > On Fri, Oct 24, 2008 at 6:27 PM, Wu, Billy <[EMAIL PROTECTED]> >> > > wrote: >> > >> Hi everyone, >> > >> >> > >> >> > >> >> > >> I have a large tree (500 nodes under a node), and it is taking a >> > >> very long >> > >> time to load (like 46 seconds) in Internet Explorer. In Firefox >> > >> and Chrome, >> > >> it only takes a few seconds. Unfortunately my company has to >> > >> support IE. >> > >> Does anyone know a good solution to this? (Maybe like a TreePanel >> > >> widget >> > >> that will go get data as needed?) >> > >> >> > >> >> > >> >> > >> Thanks, >> > >> >> > >> >> > >> >> > >> Billy >> > > >> > > >> > > >> > > -- >> > > Matthias Wessendorf >> > > >> > > blog: http://matthiaswessendorf.wordpress.com/ >> > > sessions: http://www.slideshare.net/mwessendorf >> > > twitter: http://twitter.com/mwessendorf >> > >> > >
