157401 - Regression causing "frame drop-offs" [DHTML]

Status: RESOLVED FIXED

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

Description

[Markus Hübner]

This is quite similar to what we have had with bug 129953.
Just go to http://www.formula-one.nu/dhtml/3d.htm - in recent builds major 
frame drop-offs happen. 
think that bug 124685 could be the reason.

just see bug 153083 comment #6 and 7.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

confirming. Horrible framing, horrible speed. Thankfully this one doesnt hang
Mozilla.

Comment 2

[José Jeria]

Even worse, try this out:
http://www.formula-one.nu/dhtml/moz3d.htm

And change the "Chante timeout" selectbox to 1...

Comment 3

[Kai Lahmann (is there, where MNG is)]

on Linux (Build 2002071211) the animation stops short and restarts at the same
position as far as I can see. Not really visible here

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

On my Linux (trunk 2002070813/Xeon 1Ghz) i cannot trully call it "animation".
It's a unregular slide show.

Comment 5

[Markus Hübner]

Another URL from a n.p.m.performance posting is
http://www.13thparallel.com/?issue=2002.07&title=sigslots
(there is hardly any scrolling).

Comment 6

[Markus Hübner]

on recommendation of jesup reassigning to waterson.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

These URLs may be totally unrelated bugs.  Should they really all be clumped
into the same bug report?  I think waterson has other things to work on lately,
and probably isn't the best owner for this.

Comment 8

[Markus Hübner]

If this URL specifically deals about this problem or not - this is a major 
regression affecting all kinds of animation. And it should be really fixed for 
1.2 milestone.
you can easily see the problem for example at:
http://www.formula-one.nu/dhtml/3d.htm

Who would be the best owner for this?

Comment 9

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

Jprof's would be useful, perhaps with/without the 124685 patch

dbaron - you may be right, I don't know what waterson is up to currently.  Feel
free to reassign to whomever (you, jst, me, etc)

Comment 10

[Markus Hübner]

just for illustration of the problem:
http://3dhtml.netzministerium.de/examples/openinghexcube3d.html
this one is heavily hurt

Comment 11

[Brendan Eich [:brendan]]

waterson's off on a new project -- try persuading someone else if you want
results soon.  Maybe bz?

/be

Comment 12

[Boris Zbarsky [:bzbarsky]]

Like I said in the newsgroup, I can't actually reproduce these "drop-offs" on
the machine I have here.  I would need a slower machine, I suspect.

This is claimed to be a regression.  Do we have a regression date?  matic, that
should be the first thing to determine for regressions....

Is this a Windows-only regression?  I know Zbigniew says Linux is slow as well,
but was it always that way or is that a new problem?

Give us something to work with here, folks.  ;)

Comment 13

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

From a jprof I can't attach because it's 660K:

63% in XPCWrappedNative::CallMethod
  26% in nsDOMCSSAttributeDeclaration::ParsePropertyValue
   9% in nsScriptSecurityManager::CanAccess (mostly in
nsScriptSecurityManager::doGetObjectPrincipal)
  33% (incl from elsewhere) in nsCSSFrameConstructor::AttributeChanged
     21% in FrameManager::ReResolveStyleContext
        6% in RuleHash::EnumerateAllRules
    1.7% in nsRuleNode::ClearCachedData
2.5% in memset
5.5% in nsViewManager::RenderViews.  I should note that RenderViews only gets
called from the gtk_idle loop, which only gets called if we're not busy doing
other things (like executing JS code).  The problem is both the speed we execute
the JS code, and that all painting is supressed if we have other things to do.

Comment 14

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

Attachment: gzip'd jprof of URL (Linux RH7.1, dual-450 P3, local trunk build updated today)

gziped file

Comment 15

[Markus Hübner]

bz: see bug 153083 comment #c6
seems the bug causing this regressions also caused some other problems.

Comment 16

[Markus Hübner]

bz: about regression time:
testing trunk build 2002061014 works fine
testing trunk build 2002061208 is broken

does kin's comment in bug 153083 comment #11 relate to a possible solution 
here?

Comment 17

[Ere Maijala (slow)]

I checked in a fix for bug 153083. Does it help here also?

Comment 18

[José Jeria]

WFM using build 20020730. The URL mentioned in comment 2 works fine now.

Comment 19

[Markus Hübner]

doing extensive testing with trunk build 2002073019 shows that things are 
fixed :)