DHTML Animated Menus Performance Sluggish

RESOLVED WORKSFORME

Status

()

Core
DOM
RESOLVED WORKSFORME
17 years ago
4 years ago

People

(Reporter: psych3, Unassigned)

Tracking

(Blocks: 1 bug, {perf})

Trunk
Future
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DHTML PERF], URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.

Updated

17 years ago
Blocks: 21762
Keywords: perf

Comment 1

17 years ago
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.
OS: Windows 2000 → All

Comment 2

17 years ago
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?
(Reporter)

Comment 5

17 years ago
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

Comment 8

17 years ago
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

17 years ago
Created attachment 47954 [details]
Log of mousing over the menus

Comment 10

17 years ago
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).


Updated

16 years ago
Blocks: 113492

Comment 12

16 years ago
the URL in this bug is a 404

Comment 13

16 years ago
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

16 years ago
*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)

Updated

16 years ago
No longer blocks: 113492

Updated

15 years ago
Blocks: 113492
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

Comment 16

14 years ago
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: 14 years ago
Resolution: --- → WORKSFORME

Updated

13 years ago
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.