83088 - DHTML Animated Menus Performance Sluggish

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[psych3]

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.

Comment 1

[James Green]

There are multiple problems on this page:

1) The URLBar changes to about:blank. No idea on that one.

2) Major performance problem loading it. It takes ages. Initial JavaScript
   loading problems are covered in another bug, I believe Brendan has it, ccing
   him.

3) Once loaded, the page continues to take 100% cpu. This does not help testing
   the DHTML Menus. I should point out to the reporter that other performance
   bugs exist that deal with this site, and seperate ones covering DHTML menu
   speed.

Tested on cvas tip build today, linux.

Comment 2

[James Green]

Duh, hit the confirm button this time.

Comment 3

[Brendan Eich [:brendan]]

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

Comment 4

[Johnny Stenback (:jst)]

How is this different from bug 77456?

Comment 5

[psych3]

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. 

Comment 6

[Johnny Stenback (:jst)]

The url-of-iframe-in-urlbar problem is a known bug.

Comment 7

[Johnny Stenback (:jst)]

Marking Future for now...

Comment 8

[Fabian Guisset]

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.

Comment 9

[Fabian Guisset]

Attachment: Log of mousing over the menus

Comment 10

[Fabian Guisset]

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...

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

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).

Comment 12

[R.K.Aa.]

the URL in this bug is a 404

Comment 13

[Markus Hübner]

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.

Comment 14

[Mathew McBride]

*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)

Comment 15

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 16

[José Jeria]

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.