107091 - Moving absolutely positioned DOM elements with JavaScript is very slow on OS X

Status: RESOLVED FIXED

(Core Graveyard :: GFX, defect, P1)

Description

[Ari]

JavaScript code that changes the position of DOM elements is often unacceptably
slow on the recent Mac OS X trunk builds (up to 10/26/01). This does not appear
to be a problem in the 10/26/01 Win32 trunk build.

In the example URL, try scrolling the announcements pane by hovering over the
'newer' and 'older' links. Compare the scrolling speed with IE 5.1 on Mac OS X
or with Win32 Mozilla or IE. The scrolling pane is absolutely positioned.

What made me think that this bug has something to do with absolute positioning
is that the following test case is fast
http://bugzilla.mozilla.org/attachment.cgi?id=27275&action=view
but this test case is slow
http://bugzilla.mozilla.org/attachment.cgi?id=12242&action=view

The only major difference that I can see between these test cases appears to be
that the 'ticker' DIV element is relatively positioned in the former and
absolutely positioned in the latter.

Comment 1

[Ari]

My suspicions about absolute positioning being the cause have been confirmed
have been confirmed because just changing the 'ticker' elements's positioning to
relative in the second (slow) test case makes it fast.

Comment 2

[Boris Zbarsky [:bzbarsky]]

compositor, as a first bet.

Comment 3

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list
to schedule bugs for post Mozilla1.0 milestones

Comment 4

[Paul Bergsagel]

I rean the two test cases using Mozilla build 2002040108 uisng a B/W G3 Mac with
256MB OS X 10.1.3. I cannot see any difference in the scroll speed between the
two. IMHO tthis bug can be closed as WFM.

Comment 5

[Ari]

yeah, this seems to work now

Comment 6

[Markus Hübner]

Is this related to Sam's comment "The mozilla osx port would need use a native 
(asm or compiler) fastram PRLock implementation, not an PRLock that uses 
operating system api lock/unlock."

Comment 7

[Markus Hübner]

Is this still slow?

Comment 8

[Garrett Smith]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 
Chimera/0.6+

http://bugzilla.mozilla.org/attachment.cgi?id=27275&action=view
and 
http://bugzilla.mozilla.org/attachment.cgi?id=12242&action=view

appear to be the same speed. I'd say its FIXED 


(Chimera adds a long horz scrollbar at the beginning of each anim. During the anim, the 
scrollbar slowly disappears.)

Can we mark this as FIXED?

Comment 9

[Wayne Woods]

WFM OSX 10.2.8 rv:1.7a Gecko/20040131

Looks like this bug was forgotten about. I'll set as fixed.