In NS6.01 the menus at the url provided work well and arent sluggish in fact they work better than in IE. However with mozilla build 2001052104 the performance of the menus is very sluggish.
OS: Windows 2000 → All
Duh, hit the confirm button this time.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have no bug on user-defined JS loading slowly, and know of no such bug. Make sure you have a testcase that implicates the JS engine, not the DOM (one way to tell is to feed the script(s) to the JS shell or to xpcshell). /be
How is this different from bug 77456?
Becuase here the menus are animating but are just sluggish in comparison to NS6. With bug 77456 there is no movement of the lines whatsoever. Its also a different js animation technique On the about:blank issue, that page is in a frameset with a hidden blank frame. The frameset has an xhtml 1.0 framset DTD, the main content page has HTML4 DTD and the externally loaded pages go back to an XHTML DTD so i can load external xml data. Its the only way I can do anything at all dynamically when using XHTML with Mozilla apart although toggling visibility works, but little else does. That is if you use a XHTML DTD in the main page then everything breaks in mozilla. So somewhere, mozilla is picking up on that hidden blank frame and having that in the url bar.
The url-of-iframe-in-urlbar problem is a known bug.
Whiteboard: [DHTML PERF]
Marking Future for now...
Target Milestone: --- → Future
Hey Eddie, it's me again ;-) I just took a look again at your site, and wow, I was amazed at how well it has evolved. Honestly the design is a killer. I still see the DHTML menus being slow however. jprof log coming up.
Randell, I added you to the CC list so you can take a look at the jprof log. Probably you will be able to detect more strange things than me. Thansk in advance. - 36% of the time is spent in nsEventStateManager::PreHandleEvent (lots of event code, which makes sense since most of the activity is mouseover and mouseout) - nsGenericElement::HandleDomEvent() calls itself recursively?! - 29% of the time is spent in nsGlobalWindow::RunTimeout (which makes since there is quite a few timeout code in the menus) - ~19% of the time is spent in nsDOMCSSAttributeDeclaration::ParseDeclaration (mainly because of clip attributes and moz-opacity) Note that the menus get much faster if you run them without the sound, the flash, the other animations, etc...
FrameManager::ReResolveStyleContext is an interesting one. http://bugzilla.mozilla.org/attachment.cgi?id=47954&action=view#98461 21 hits, 1 direct. CalcStyleDifference seems to be a top callee. It's called more from SetClip than setbackground or opacity or visibility. I'm surprised how much time is spent in nsRenderingContextGTK::SetClipRect. nsGenericHTMLElementTearoff::GetOffsetHeight calls nsGenericHTMLElement::GetOffsetRect calls nsDocument::FlushPendingNotifications which invokes reflows. this may or may not (probably not) an issue. nsEventStateManager::GenerateMouseEnterExit is a main routine, but that's not too surprising. it'd be interesting to see what happens within that (lots of DOM event stuff).
the URL in this bug is a 404
Just go to http://dhtmlnirvana.com/ and click on 'Open Cyborg'. With the latest build (with patch for bug 129115) the menu is still slow and not very responsive.
*outdated, worksforme*. Bug is outdated, new menu uses shockwave-flash plugin. Using: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020608 (SeaMonkey build Mozilla/1.1 Alpha)
Mass-reassigning bugs to firstname.lastname@example.org
Assignee: jst → dom_bugs
This bug is quite outdated, site has also been redigned more than once since bug was reported, resolving as WFM. Please reopen, if you can reproduce.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.