117601 - Slow Image Rendering - DHTML animation/clipping

Status: RESOLVED WORKSFORME

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

Description

[piglet]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

Rendering of images appears very slow when compared to the same page in NS4.

This page clips images and moves them round the screen...the number of images
being moved and clipped makes it very apparant.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.daisy.fslife.co.uk
2. Wait for the images to be loaded and the slideshow to start.
3.

Comment 1

[alge]

Reporter: How fast should it be? Looks ok with 2001122808/linux on an athlon
1.4Ghz.. Takes about 5sec from one image "disintegrates" until another is
displayed. Couldn't compare it with anything useful as I don't have ns4 and
opera doesn't display the slideshow at all.

Comment 2

[piglet]

I'm running on an OK P3 w 255MB Ram.

There are two sliced images - one using 30 steps, one using 45 steps.
The timeout between steps (movements of each images slice) is setTimeout
("foo.animate()", 30)
The timeout after the image has been assembled is 3 seconds.

So...the minimum time possible for two images (one in, view delay, one out) to 
be displayed assuming the rendering takes no time is:

45*30 + 3000 + 30*30 = 5.25 seconds 

On this machine:

IE5.0 takes about 5.5 seconds
NS4 (Communicator 4.5) takes about 5.5 seconds
Mozilla takes between 15 and 20 seconds and the CPU fan kicks in

Timings not very scientific - by the second hand of my watch - but you get the 
idea of the difference in speed.

Comment 3

[Dimitrios]

related to bug 64516?

Comment 4

[R.K.Aa.]

-> DOM Level 0
This is likely a dup. DHTML performance tracker bug is bug 21762

Comment 5

[Fabian Guisset]

DHTML perf bug, marking as NEW. blah.

Comment 6

[Markus Hübner]

Confirming - really slow also when testing with the new exp. reflow build

Comment 7

[Markus Hübner]

This is affected by bug 124150.

Comment 8

[Markus Hübner]

stephen, the testcase seems no longer be available.

Comment 9

[piglet]

Yes - sorry - I've moved to a diferent server. THe URL is now:

http://homepage.ntlworld.com/

Comment 10

[piglet]

Yep - I's a Monday Morning....

http://homepage.ntlworld.com/thepiglet

Comment 11

[Markus Hübner]

piglet, trying a recent build what do you think about performance?

Comment 12

[piglet]

Hi Markus,

I have been following the improvements in Mozilla (extolling the greatness of
the browser on http://www.webxpertz.net/forums/) and have to say that there has
been a tremendous improvement in DHTML performance since reporting this.

Today, using Moz 1.3a or Phoenix 0.5/Win NT the performance is pretty good. I
then looked at the animation using IE 5.5 <blowsOffDust />. In IE the animation
appears completely smooth - and when you go back to Moz it looks quite jumpy in
comparison.

In previous versions of Moz anything like this animation put the CPU up to a
constant 100% and froze from time to time.

Pulling up the Task Manager with IE5.5 animating the page, the CPU usage on this
P3 machine moves from 0% when stationary to a peak of 28 to 32% on each
animation cycle (though it had some higher peaks when I decided to go back and
do a screen print...)

With Moz 1.3a animating the page, the CPU usage on this P3 machine moves from 0%
when stationary very quickly to a peak of 100% on each animation cycle.

So - great work. It's loads better, but there's still a way to go before the
DHTML performance is as good as we'd like it to be. The CPU usage still seems
rather too high. I wish I had the skillset to be able to help, but I don't
expect you use COBOL much!

Comment 13

[piglet]

Attachment: BMP screen capture of Moz/IE CPU Usage

Comment 14

[Markus Hübner]

Sure - there's still enough to do.
Bug 157681 will be another step towards improving our overal DHTML performance 
and roc is also working on optimizing our painting performance [bug 170330, 
bug 136688 ].

Comment 15

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 16

[José Jeria]

I would say that Mozilla is equally fast as IE on this url...

Comment 17

[Fabian Guisset]

Using firefox0.8 on win2k (1ghz athlon, 256MB RAM) we are doing better (0%-55%)
than IE6 (0%-90%) actually. piglet could you give us an update on what you are
seeing with recent builds? Thanks!

Comment 18

[Martijn Wargers (dead)]

The url is 404 now...

Comment 19

[Markus Hübner]

The web archive does it: 
http://web.archive.org/web/20040930173040/homepage.ntlworld.com/thepiglet/

Comment 20

[Martijn Wargers (dead)]

Attachment: testcase

Ok, this is a not minimized testcase based from that archive page.

Comment 21

[Martijn Wargers (dead)]

Attachment: testcase

Same testcase, but also works in older builds.

Comment 22

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

WFM with Firefox3beta5pre on WinXP

Comment 23

[José Jeria]

WFM too, build: Mozilla/5.0 (Windows; Windows NT 6.1; rv:2.0b3pre) Gecko/20100728 Minefield/4.0b3pre