319739 - Firefox 1.5 performance regression: Significant javascript animation performance degradation involving certain element positioning (float+relative+absolute)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Scott Schiller]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; yie6; SV1; .NET CLR 2.0.50215; Avalon 6.0.5070; WinFX RunTime 3.0.50215)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When using javascript to animate some elements, Firefox 1.5 appears to be very CPU-intensive and significantly slower when rendering/redrawing a particular combination of relative, absolutely-positioned and floated elements. This seems to be a regression from Firefox 1.0.7, which does not exhibit this issue.

Reproducible: Always

Steps to Reproduce:
1. Open example URL
2. Observe reported animation run time, compare between Firefox 1.5 and Firefox 1.0.7 (eg. ~3000 msec vs. ~700 msec)
Actual Results:  
Animation sequence can average >3000 msec under Firefox 1.5 on WinXP SP2 (2.8 GHz P4), CPU use is 100% throughout.

Also tested on OSX 10.3.9, 800 MHz PowerPC G4, animation times as follows:
Firefox 1.0.6: ~600 msec
Firefox 1.5: ~9000 msec

Expected Results:  
Animation sequence should average <1 second to execute under Firefox 1.5 (as with Firefox 1.0.7 and IE 6,) with very little CPU use.



The test page uses a relatively-positioned container element which has two immediate children - a relative DIV(1), and a UL(3).

The test page markup structure is as follows:

<div>

 <div> <!-- (1) -->
  <div> <!-- (2) -->
   <img />
   <img />
   <img /> 
  </div>
 </div>

 <ul> <!-- (3) -->
  <li>text</li>
  <li>text</li>
  <li>text</li>
  <!-- .. many more LIs .. -->
 </ul>

</div>

Within DIV(1) is a relative DIV(2) containing images, and the UL(3) has many floated LI elements.

A javascript function called via window.setInterval() sets a marginLeft style property on DIV(2), causing it to move from left to right and back again within its parent in a fixed-frame animation sequence.

The performance hit (high CPU usage and thus low redraw/refresh/frame rate) seems to stem from the floating of the LI elements underneath. Removing the float seems to alleviate the problem, but does not provide the fluid layout desired.

Given this element's container is absolutely positioned, this element should in effect be on its own "layer", able to move freely and should not affect the redraw of any other elements outside its parent container (please advise/correct if this is not the case.) Firefox 1.0.7 renders this page without issue. However in Firefox 1.5, it appears that the browser also seems to be redrawing or doing calculations relating to the LI elements, causing a significant performance hit.

Comment 1

[José Jeria]

Attachment: Testcase

I noticed that removing "position:relative" from the #container class is enough to make the testcase fast again. 

Click on the headline to change the container element's position from "relative" to "static" to see this

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 281267 -- the patch for that bug made messing with the abs pos kids of a rel pos block reflow all of its in-flow kids; not doing that screwed up clear in some cases.

Chances are this is just something we should revisit after we land the reflow branch...

I'm not sure there are any obvious good workarounds here.

Comment 3

[Jon Granrose]

Hey Boris - I haven't been following the tree, but I'm guessing the reflow branch already landed.  Any new insight into this?  We have some nasty workarounds in place to get around this that we'd like to be able to get rid of...  Thx!

Comment 4

[Boris Zbarsky [:bzbarsky]]

The reflow branch hasn't landed.  See http://wiki.mozilla.org/Gecko:Reflow_Refactoring for status.

Once it does land, we'll reexamine all the [reflow-refactor] bugs.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Another workaround is to make "container" a float, say "float:left". (This ensures that the geometry of the floated LIs won't be needed to fix up any later cleared elements.)

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Scott or Jon, now that the reflow branch has landed, do you guys still see the problem with a current trunk or Firefox 3.0 beta build?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Oh, and FWIW, I'm seeing about 600-700ms on the attached testcase with Fx3.0b2 on my 1.7GHz Pentium-M laptop.

Comment 8

[Scott Schiller]

(In reply to comment #6)
> Scott or Jon, now that the reflow branch has landed, do you guys still see the
> problem with a current trunk or Firefox 3.0 beta build?

Firefox 3 Beta 2 is looking good, 500-600 msec with a 2.16 GHz Core 2 duo MBP (OSX 10.4.11.)

I've noticed fx3 is notably faster than fx2 for a lot of layout/redraw stuff in testing on JS/CSS-heavy designs; a job well-done and kudos to the team.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Marking FIXED by the reflow branch per comment #7 and comment #8. Thanks for replying so fast, Scott!