Closed Bug 70100 Opened 24 years ago Closed 23 years ago

Horizontal Rule in motion via DHTML eats CPU.

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: bugzilla, Assigned: waterson)

References

(
URL
)

Details

(Keywords: perf, testcase)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010215 BuildID: 2001021508 When an HTML block containing a horizontal rule (<HR>) is set in motion by incremental positioning, CPU usage gradually rises to 100%, and the time between steps gradually increases. Reproducible: Always Steps to Reproduce: Set a <div> in motion via JavaScript. Place a <HR> anywhere inside it. Actual Results: Motion gradually slows (time in between positions increases). CPU usage grows to 100%. Removing the horiz. rule eliminates the problem. If the HR is itself moved in this manner (instead of its containing div), no slowdown occurs. This has been reproduced on 3 out of 3 Win2K machines. Test pages are at: http://www.screaminweb.com/mozillatest/slowHR.html http://www.screaminweb.com/mozillatest/noHR.html
Confirming with build 2001022200 on NT
Marking New as per comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf, testcase
qa contact updated.
QA Contact: gerardok → bsharma
changing the component to 'Layout'.
Assignee: clayton → karnaze
Component: HTML Element → Layout
QA Contact: bsharma → petersen
Target Milestone: --- → mozilla0.8.1
Reassigning to Buster's list.
Assignee: karnaze → buster
Target Milestone: mozilla0.8.1 → mozilla0.9
Moving to m1.0 and reassigning to waterson.
Assignee: buster → waterson
Target Milestone: mozilla0.9 → mozilla1.0
Blocks: 77421
Blocks: 21762
Status: NEW → ASSIGNED
still seeing slow down on build 2001102903 win32 trunk but not really *that* noticable and CPU does not reach 100% until about half way down the page.
this seems to be fixed maybe due to the fix in bug 71979 ? Or maybe something else
forgot to mentioned that I tested with build 2001112104 win32
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
WFM on Linux with Build-id:2001113006, the cpu use stays at 0% and it doesn't deccelerates when scrolling down,just scrolls cleanly.
Nice! It works for me now too, Win2K build 2001120208. Resolving as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Sory for the spam, but I'd REALLY like to know what in code caused this change in last week. It looks unbelievable that one week old Mozilla eated 100% on this and the new one only about 20%...
No longer blocks: 21762
Blocks: 21762
You need to log in before you can comment on or make changes to this bug.