The default bug view has changed. See this FAQ.

[DHTML] Tracking bug for performance on simple layer animation/movement

RESOLVED INCOMPLETE

Status

()

Core
Layout
RESOLVED INCOMPLETE
14 years ago
7 months ago

People

(Reporter: Markus Hübner, Assigned: Markus Hübner)

Tracking

(Blocks: 1 bug, {perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Assignee)

Description

14 years ago
This one is for keeping track on the performance of the simple layer 
animation/movmenet tests at
http://www.world-direct.com/mozilla/dhtml/funo/dhtmltest1to10ms.htm
[for intervals of 1ms to 10ms]
and
http://www.world-direct.com/mozilla/dhtml/funo/dhtmltest_10to20ms.htm
[for intervals of 10ms to 20ms]

My system, PIII 1.1ghz,512ram,32mb geforce2go

trunk build 2003062408
 1-10ms : 4239.1ms
10-20ms : 5303.09ms

MSIE 6 SP1
 1-10ms : 2539.7ms
10-20ms : 4806.00ms

Opera 7.11
 1-10ms : 2522.6ms
10-20ms :  4814.27ms

Mozilla1.3
 1-10ms :  4235.1ms
10-20ms :  4806.00ms

Mozilla1.2.1
 1-10ms :  4216.1ms
10-20ms :  5307.63ms


Depending on the selected ms timeout the animation is most of the time quite 
choppy. This is very similar to the findings mentioned in bug 129496 (running 
smooth, then choppy, smooth again, choppy again, etc.) - maybe this might also 
get better once bug 123668 is in.
MSIE and Opera are running smooth througout all timeout values.
(Assignee)

Comment 1

14 years ago
Or maybe we can tweak our performance in the 1-10ms range (which is most used 
on the web) by optimizing the PL_Event notification resp. bug 169247 ?
QA Contact: ian → markush

Comment 2

14 years ago
hard to guess if that is correct.  you might want to try counting the number of
PLEvent objects allocated during a typical test run.

Comment 3

14 years ago
yeah, I think we need some profiling done here before we can really see what's
going on. Also, I sped up getElementById() recently, it might be worth seeing if
that affected this.

Comment 4

14 years ago
just for the record here's some basic numbers on the mac side. Moz builds are
what i had on hand. someone wanna take a stab at the best set of builds to test?

g4/400mhz/1gbram

best of 2 or 3 runs

        moz1.0.2   moz1.4  moz03070108  safari1.0  msie5.2.3
test 1    2874.6*  3277.3       3240.9    10693.7     2260.0
test 2    5112.7   4531.5       4510.9    10833.2     4253.0

* first 2 passes seem to go without painting
(Assignee)

Comment 5

14 years ago
Kmcclusk once made timeouts to be a minimum of 10ms if I remember correctly - 
but MSIE is having also this behaviour afaik - but is doing things a lot 
faster. 
Hopefully a profile will bring up some light here.

Comment 6

14 years ago
To count PLEVent objects:

You can do this:

a) define PL_POST_TIMINGS in xpcom/threads/Makefile.in

b) on line 707 of plevent.c, change the printf to report s_eventCount.

c) rebuild xpcom/threads and xpcom/build.

This will print you the number of total PLEvents that have been properly 
destroyed.

Comment 7

14 years ago
Made this test on a 2,53Ghz P4 with Win2K and a Radeon 9500 Pro on current CVS
trunk build (with that Patch for Bug 83536, perhaps that's related, i heard so
from matic :)
test1to10ms:
Average time: 2689.1ms
test10to20ms:
Average time: 3917.6363636363635ms.

More detailed test :
test1to20ms
1ms timeout : 2688ms.
2ms timeout : 2687ms.
3ms timeout : 2688ms.
4ms timeout : 2687ms.
5ms timeout : 2688ms.
6ms timeout : 2687ms.
7ms timeout : 2703ms.
8ms timeout : 2688ms.
9ms timeout : 2687ms.
10ms timeout : 2688ms.
Average time: 2689.1ms

test10to20ms:
10ms timeout : 2688ms.
11ms timeout : 2922ms.
12ms timeout : 3187ms.
13ms timeout : 3422ms.
14ms timeout : 3656ms.
15ms timeout : 3906ms.
16ms timeout : 4172ms.
17ms timeout : 4407ms.
18ms timeout : 4656ms.
19ms timeout : 4922ms.
20ms timeout : 5172ms.
Average time: 3919.090909090909ms.

I noticed on both tests that when i press the start button more and more the
timeout decreases more and more and the animation gets faster. btw: Also when a
page with many tables/complicated tables(?) loads in another tab, the average
time incresaes about 1 second, but that's another issue (example page would be
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey).

Comment 8

14 years ago
>>
I noticed on both tests that when i press the start button more and more the
timeout decreases more and more and the animation gets faster.
<<

Thats a bug in the testcase. It's resolved in
http://www.world-direct.com/mozilla/dhtml/funo/dhtmltest1to10ms_modified.htm but
the benchmark output for the TimeOut line is corrupted.

Comment 9

14 years ago
I've attached a patch in bug 213813 that might help with some of these DHTML
issues. I don't expect tremendous gains, but it might be a small step in
improving performance. I'm going to try and get some numbers, but I wanted to
get this out to others that might have more time than I have current. The patch
is at http://bugzilla.mozilla.org/attachment.cgi?id=128862&action=edit
(Assignee)

Updated

14 years ago
Depends on: 213813
QA Contact: markushuebner → layout

Comment 10

10 months ago
test page is offline so please close this bug

Updated

10 months ago
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.