[DHTML] Speed issue with DHTML based Javascript (animation)

NEW
Unassigned

Status

()

15 years ago
a year ago

People

(Reporter: daniel.decourdemanche, Unassigned)

Tracking

(Blocks: 1 bug, {perf, testcase})

Trunk
x86
Windows XP
perf, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507

I recently ported a RPG graphical javascript game from IE to Mozilla & Opera.
The game works now fine with every browser, but it is really slow on Mozilla,
more than 30% slower. It's a big problem because de page's code is the same for
all browsers, the javascript is standard compliant, the computer is the same in
powerness...
Mozilla needs to be optimized step by step during the devlopment. You are wrong
if you plan to do the job later, as a 36 years old programer, I think I did the
same errors long ago, and wont do anymore.

The work in progress privat epage for the game core is :
http://perso.wanadoo.fr/avalon-games/cross.htm


Reproducible: Always

Steps to Reproduce:
1. Run the page
2. direct the character on the map
3. see the poor speed

Actual Results:  
Doesn't apply

Expected Results:  
hope to have the same speed thant IE and Opera.

What could I do? If no solution is fond, I will advice my visitors to switch to
a quicker browser to play tha game.

Comment 1

15 years ago
This does not block Mozilla development.
Severity: blocker → normal

Comment 2

15 years ago
To really help Mozilla:
 - provide a reduced testcase,
 - use a profiling tool http://www.mozilla.org/performance/tools.html to see
where the slowliness is exactly.
see bug 157072, bug 210602, bug 157681. There are plenty of perf bug reports
already to be worked on: bug 203448.

Comment 3

15 years ago
@reporter: Mozilla has done a lot of improvement in layout as well as 
especially in DHTML related areas. When you say "slow" what exactly are you 
refering to? 
What would be needed is something that can be measured - for example a 
simplified testcase with some scrolling as done in the game from point A to 
point B and at the end printing the number of time needed for that.
So then, this result can the be compared to other browsers respectively 
previous Mozilla versions. And developers can analyse the testcase for 
optimizing Mozilla.

Component: Image: GFX → Layout
Keywords: perf

Comment 4

15 years ago
Testcase has been provided at:
http://perso.wanadoo.fr/avalon-games/benchmark.htm

Confirming - and this is horrible slow! 
Haven't seen Mozilla behaving like that for ages - eager to know what happens 
here [profile would help]

MSIE6:             17535ms
Trunk 2003072204: 255398ms



Blocks: 21762
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase

Updated

15 years ago
Summary: Speed issue with DHTML bases Javascript → [DHTML] Speed issue with DHTML based Javascript (animation)

Comment 5

15 years ago
If you could test with a few builds and find a timeframe for when it slowed down
that might allow someone to determine the check-in that caused the problem.
Assuming it's one check-in and not the combine effect of multiple ones.
Created attachment 128339 [details]
Realtime jprof profile, 2ms timer

Interestingly, it takes about 50 seconds to run the testcase on my machine.  I
would thus expect somewhere on the order of 2500 profiler hits (one every 2ms
for 50 seconds).  That's about what I see with the non-realtime profile, but
the realtime one shows twice that many hits....

In any case, the numbers are close enough between the two profiles as far as I
can tell, so attaching the realtime one.

Things to note:

1)  Total hit count: 5041
2)  Of the total, hits under evaluating the string when the timer fires: 4386
3)  Of the total, hits under gdk event stuff (gdk_event_prepare, g_main_poll,
    etc): about 400
4)  Of the total, hits under actually reflowing the page: 235

That sort of sums up where the total time is spent.

So total time spent evaluating the JS timeouts: 4386 (under
nsJSContext::EvaluateString).  Of this:
A) 115 hits under nsJSContext::ScriptEvaluated
B) 146 hits under jsd_FunctionCallHook
C) 2455 hits under XPCWrappedNative::CallMethod
D) 304 hits under js_ValueToNonNullObject
E) The rest seems to be spent in various JS engine and XPConnect overhead

Of the 2455 hits under XPCWrappedNative::CallMethod:
A) 1405 hits under XPTC_InvokeByIndex
B) 673 hits under nsScriptSecurityManager::CanAccess
C) 101 hits under NativeInterface2JSObject
D) The rest is various XPConnect overhead, looks like

Of the 1412 hits under XPTC_InvokeByIndex (7 came from	XPC_WN_GetterSetter):
A) 990 are under nsDOMCSSDeclaration::SetProperty
B) 299 are under nsDOMCSSDeclaration::GetPropertyValue
C)  66 are under GlobalWindowImpl::Alert (that's the time it took me to stop
the
       profile once the alert came up)
D) Remaining 40-some are sorta scattered about

Of the 990 hits under SetProperty:
A) 69 are under parsing the new value
B) 898 are under setting the new value (792 in ComputeStyleChangeFor and 88 in
   ProcessRestyledFrames)

Of the 299 hits under GetPropertyValue:
A) 101 are under nsString::AppendFloat
B)  48 are under string appending
C)  35 are under GetCSSDeclaration
D) The rest seem to be scattered about

So conclusions:  Of the 5041 hits, 235 are spent in reflow, the rest in
processing the timeouts and event overhead.  Of the 4386 hits under processing
timeouts, only 1412 hits are under actually talking to the objects the methods
are being invoked on.  The rest is JS engine overhead, security manager,
XPConnect overhead, etc.
ccing some people who know JS engine and xpconnect better than I, in case they
have bright ideas...

A few comments I have based on looking at the testcase:

1)  The timing the testcase performs is NOT done via actual timing functions (eg
    the JS Date class), but via timeouts that it sets at 1ms intervals with no
    purpose but to increment the counter by 1.  Since these timeouts are racing
    with the 1ms timeouts that actually move things around, I question the
    validity of the times they generate.  Using the Date class would be a lot
    more reliable.
2)  Things like setTimeout("callFunction()", 1) are guaranteed to be slower than 
    things like setTimeout(callFunction, 1). The testcase uses the former and I
    would be interested in seeing how the latter performs.

In light of these two items, the incredible JS overhead I was seeing in the
profile makes perfect sense -- the page is running a bunch of JS that has
nothing to do with anything and doing so in the slowest way it can.
bz's right.  Point 2 especially: you are re-invoking the JS compiler to
recompile bytecode for "callFunction();" on every setTimeout.

Use the funarg force, Luke.

/be
(Reporter)

Comment 9

15 years ago
I added an option 2 the benchmark so user can choose with or without Gif 
animation, as requested.

In IE, the results are the same ; With Moz, it saves about a second.
The URL remains the same : http://perso.wanadoo.fr/avalon-games/benchmark.htm

I must say regarding to the comments that the page does run a bunch of JS 
(collision detection, layer Zordering on the fly, mouse capture etc...) 
volontary. The purpose to this is to test the javascript/DHTML speed of any DOM 
browser the hard way.

Sofrom my point of view, the speed of the code itself isn't interesting at all, 
it's the comparative speed of browsers running the same code that imports no?

Try the URL with IE or Opera. IE is part of the OS, so it's speed isn't really 
a big surprise, but Opera does not! And its speed is allmost the same. If 
someone could explain.

This bench is just an implementation of my core game engine witch purpose is to 
play online a RPG game, the bench idea came later...
> Sofrom my point of view, the speed of the code itself isn't interesting at all, 

Yes, but the extraneous noise it generates makes it very difficult to sort out
the rest of the profile...

If you could possibly make a testcase that addresses my two comments, just
comparing performance on those two testcases would tell us a good bit about
what's going on here.
(Reporter)

Comment 11

15 years ago
I just uploaded the pages featuring the second comment fixed.
The other (the date class use instead of timer) will be done later this days 
because I have to take some advice from a friend of mine, who isn't online 
right now.
(Reporter)

Comment 12

15 years ago
Well, I did the code with the fixes requested about the setTimeout timer and 
the date based milisecond counting for time measure.

I couldn't take advice from my friend javascript "guru" at 
http://www.toutjavascript.com that could be translated from french to english 
by "http://www.alljavascript.com".

So I did my best *all alone* and it seems to work properly.

Hope this help finding what the hell is causing the loss of speed.

;)  Dadoo.
Created attachment 128450 [details]
Non-realtime jprof profile, same 2ms timer

This is still showing that we spend a lot of time in JSeng and XPConnect.  Of
the 2375 total hits, 2332 are under PL_HandleEvent.  Of these, 120 are under
handling of reflow events, while 2209 are under handling of timeouts.

Of those 2209, 2145 are under JS_CallFunctionValue.

Of those 2145, only 1223 are under XPCWrappedNative::CallMethod (and of those
1223, 336 are in the security manager, but I don't have caillon's last patch
merged in yet).

The top functions time is spent in are:

Total hit count: 2375
Count %Total  Function Name
 39   1.6     _ZN10nsRuleNode12GetStyleDataE15nsStyleStructIDP14nsStyleContexti

 33   1.4     js_Invoke
 32   1.3     JS_GetPrivate
 27   1.1     js_SearchScope
 27   1.1     __i686.get_pc_thunk.bx
 26   1.1     js_GetProperty
 25   1.1    
_ZN14XPCCallContextC1EN10XPCContext8LangTypeEP9JSContextP8JSObjectS5_ljPlS6_
 25   1.1     _ZN16XPCWrappedNative10CallMethodER14XPCCallContextNS_8CallModeE
 23   1.0     _ZN13nsCOMPtr_baseD2Ev
 23   1.0    
_Z15SelectorMatchesR17RuleProcessorDataP13nsCSSSelectoriP7nsIAtoma

Which is not much to go on -- none of those are taking up too much of the total
time.

Brendan, dbradley, any ideas what could be eating up this much time in JS eng
and xpconnect?	We spend about 900 hits in there, which is nearly half the
time.

One other thing I would be interested in seeing is what happens when the
timeout is raised to 2ms instead of 1ms....
Attachment #128339 - Attachment is obsolete: true
(Reporter)

Comment 14

15 years ago
OK, You can find 3 options into the page setting for the bench :
- with gif animation
- without gif animation
- with a 2ms timeout
It's online.
Interesting.  The 2ms version takes just as much time as the 1ms one, suggesting
that we just take more than 1ms to process each step...

Comment 16

15 years ago
FindMember might be one spot. It showed up high on some tests I was doing. It's
a linear search of the list of interfaces then each member of each interface. It
was assumed that the interface count and member count would be relatively low.
It could be improved via a hash table scheme if that's not the case. It would be
interesting to know how many interfaces and how many members each interface has
on average. I'll try and get some metrics to see if this might provide some
improvement in this scenario. What I fear is that we'll speed up this case, but
then slow down a 80% of the rest of the code by adding the hash building code,
but maybe that cost won't be that great.
One more interesting thing... how many times does the timeout fire on that test
in Mozilla?  How about in IE?

Comment 18

15 years ago
Isn't the minimum timeout 10ms?
Oh, good point.  Yes, it is.

What do the times look like in Mozilla and IE if we set the timeout to 10ms in
the testcase?
Dbradley, maybe the hash could be created and used conditionally depending on
the size of the interface? That way we'd get the performance improvment where
needed w/o taking a hit where it's not needed...

Comment 21

15 years ago
Yes that's a good idea. I was also thinking along the lines of only adding
interfaces that get hit to the hash. That way we don't have to take the hit of
adding interfaces we never use. I've filed bug 213813 to look into the details.
Depends on: 213813
(Reporter)

Comment 22

15 years ago
As requested, I just uploaded a new version of the benchmark page featuring the 
new option for a 10ms timer.
For information purpose, IE losts some time (about 100ms) with this setting.
So 10ms seems to be the maximum setting.
So IE did not slow down significantly with the 10ms version?  Good to know.
(Reporter)

Comment 24

15 years ago
hello, turning around this bug & dev the rest of my engine I found some things 
interesting :

- If I let the scrollbars, IE becomes as slow as Mozilla, or allmost.
- If I kill the scrollbars with the CSS :
    <!--
	BODY	 {
			//overflow : hidden
		}
	-->
IE gets full speed, but this is not the case for Moz.

So I think that it has something to do with the way Moz does this stuff.
Another interestinf thing that may cost a new bug submission, with this CSS, 
the code returning clientHeigth get a wrong result in Moz (0), so the main 
character isn't well centered in Moz, but well centered in IE...

I will insvestigate this before thinking of submitting something...
Hm... we've seen this scrollbar issue come up before, though we've never made
any headway on it....

Comment 26

15 years ago
Part of that is covered in bug 170330 resp. depending bugs.

No, as a matter of fact it is NOT covered by bug 170330.  Bug 170330 covers an
issue where we repaint too big an area.  I checked the invalidation areas for
this bug using paint flashing back around comment 6, and they are correct -- had
they not been, I would have mentioned it.
(Reporter)

Comment 28

15 years ago
I found the solution for the ClientHeight wrong value reporter by completting 
the BODY CSS as follows :
BODY	 {
			margin-top : 0      ;
			margin-bottom : 0      ;
			overflow : hidden      ;
			Width : 100% ;
			Height : 100% ;
			Margin-Left : 0px ;
			Margin-Right : 0px
		}
	-->
With this code everything works just fine.
There is another new testcase on the main benchmark page with these overflow 
css and the timing of both IE and Moz.

Comment 29

15 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
(Reporter)

Comment 30

15 years ago
Ok cool, I'd like to try it, but how to get the patch installation, it seems to 
have to be compiled or anything isn't it?

Comment 31

15 years ago
Yes, it has to be applied and then compiled in. I have a zipped version of the
updated XPConnect lib for Windows which people could copy in, but zipped it's
still more than 500k, and I wasn't eager to stick it in Bugzilla. And I don't
have another place where people could get to it.
(Reporter)

Comment 32

15 years ago
Thanx to Bradley, I can host the patch file at this URl :
http://perso.wanadoo.fr/avalon-games/xpconnect.zip
I will let it here for one month.
I'm patching my own Moz right now!!!
:)
(Reporter)

Comment 33

15 years ago
With this patch I get 6 seconds better !

Comment 34

15 years ago
What sort of a % improvement that does equate to?  How does Moz measure against
the other browsers with that 6s improvement?
(Reporter)

Comment 35

15 years ago
Here are the results with the patched version of Moz running the standard 
benchmark at : http://perso.wanadoo.fr/avalon-games/benchmark.htm
Tested 08/09/03 :
*IE :    10063 ms
*Moz :   23220 ms (previous testcase result 28188) about 17% better.
*Opera : 10454 ms
Done on a p4 computer 2.4 Ghz with Nvidia Gforce 4 TI 4200 512 MO memory.
You may try with different builds and optimizations at the URL given.
;)

Comment 36

15 years ago
OK, I thought I'd try a "standard" 1.5 alpha install of Mozilla (and other
browsers) on an AMD Duron 1.3Ghz with nVidia GeForce 4 MX 220 64MB (AGP 4x).

Opera 7.11   : 25206 ms
IE 6.0sp1    : 29553 ms
Moz 1.5alpha : 39908 ms

However, I note that IE did the worst job of the 3 browsers. It "blurred" the
movement in that the items that where moving left a trail behind them. Opera
didn't have the moving eyes on the characters or the music notes above the
singer. So, in that respect, while Mozilla was the slowest, it was displaying
more than the other two browsers. So, I would say Mozilla was the best, as the
other two have either not implemented certain items, or are cheating.

Comment 37

15 years ago
What do the latest comparison results say?
(Reporter)

Comment 38

15 years ago
The test engine isn't working anymore with the new build of moz. It seems to 
be something wrong with the IFRAME tag, but it was working properly with the 
earlier version.

So I tryed with the improved game engine (but still in alpha) you can find at 
http://perso.wanadoo.fr/avalon-games/the-other-rings/index.htm

In no particular order : the scrolling is smoother, the animation correctly 
done and the speed relatively constant, even with big layers.

Comparing with the other browsers, moz is still the slower, but the improvment 
is reall. The game is almost playable, it wasn't the case at all with the 
earlier build of moz.

I know, you will need some numbers to quantisize what was done, and I'm 
working on that stuff.

DD

Comment 39

15 years ago
great - eager to see more info :)
> The test engine isn't working anymore with the new build of moz. It seems to
> be something wrong with the IFRAME tag, but it was working properly with the
> earlier version.

Can someone dig into this quickly, and file a bug if needed?  We shouldn't let
this possible regression slip by unreported by its own bug.  We might want to
fix it for 1.6.

/be

Comment 41

15 years ago
It's not an IFrame problem. If you go to
http://perso.wanadoo.fr/avalon-games/bench-gif.htm you will see the animation
sans the IFrame and other stuff.

For me (running Mozilla 1.6a) the entire graphic displays for about a second,
and then vanishes. You can still click where the graphic was, and see a very
small subset of the graphic animation running.

Comment 42

15 years ago
Dont know if you guys mean that you dont see the entire content, if yes, then 
what is causing this is bug 170011, the bodys overflow is set to hidden by 
javascript with window.onload, thats why it flashes for a sec.

Comment 43

15 years ago
It would appear that I am, in fact, seeing Bug #170011 based on the source code
of the URL I mentioned earlier.
(Reporter)

Comment 44

15 years ago
Hello, I'm terribly ennoyed with a kind of bug, noone seems to have in mind :(
 
I'm making an application with firebird as a stand alone html viewer. But When 
I start it with a command line stuff like this : start 
MozillaFirebird/MozillaFirebird.exe file:///c:./index.html in a dos bat, or 
with a front-end in delphi, the page loads good, the picture too, but i cannot 
start a video or a sound with a simple html link :(

Mozilla says to me an error has happened. For me there might be an answer in 
the way moz do tuff with local files (relative and absolute paths, regarding 
to the drive letter ?), but I cannot find a way to override this.

I know this is probably not the right topic, but if someone would be kind 
enought to send me to the right one or mail me some explanations I will be 
really helped to the max... THXXX

I had to fisnish last week, hugh ! I'm late !! ;)

Comment 45

15 years ago
Greetings, 
I have found similar problems when running my javascripted games in Firefox. My
games have many moving elements on the screen at a time and utilize image
clipping techiques for animation.

I have noticed 2 problems with Firefox.
1) setTimeout() function seems to yield inconsistent delay speeds which 
affects smoothness of animation. In my games I use 50ms delay on each loop.
2) as more elements are added to the screen the animation slows to a crawl 
very quickly. One moving element is fine, but as soon as 3 or 4 are added, then
animation slows down significantly. There seems to be a problem with the screen
updates.

If you run the game on page www.def-logic.com/freejack/index.html you will 
notice the speeds are inconsistent and rendering is extremely slow. Please 
compare with same game in IE6.

This can be confirmed on any of my javascript games at www.def-
logic.com/games.html
The first thing I see on the page is that you don't preventDefault the
keypresses your game uses, so Mozilla is doing a lot of work on each keypress
(eg running typeahead find).
Depends on: 230170

Comment 47

15 years ago
(In reply to comment #46)
> The first thing I see on the page is that you don't preventDefault the
> keypresses your game uses, so Mozilla is doing a lot of work on each keypress
> (eg running typeahead find).

True, but even when that option is switched off the speed is incredibly slow. 
Thanks for looking at the problem :)
(Reporter)

Comment 48

15 years ago
Nice game!

I thought the bug was abandonned, it's nice to see it wasn't the truth, 
because I just get 4 messages in 4 minutes! Good!

My latest observations about the speed issue is that its dependant on the main 
layer size, or the windows size. Seems very logical no.

In a new version of my own engine at http://perso.wanadoo.fr/avalon-
games/tor/level1.htm these observations are evident : you cannot play with a 
big window (or fullscreen) but if you reduce its size, it almost playable.

Funny, the newest Opera build is much slower than the previous with this DHTML 
code!

I hope someone will fix this, long is the wait.

Comment 49

15 years ago
(In reply to comment #48)
Thanks for your comments. I like the graphics in your game. Very nice :)

I think its important that this bug is pursued and not abandoned. One of my 
aims is to make my games available to everyone on the internet. As DOM 
standards are converging, this aim is close to fulfilment. But there is still 
the speed issue to contend with. At this stage I've had to put a warning on my 
games for Moz users, advising that the game will only run at correct speed in 
IE. That's a shame but I've had no choice.

Interestingly, moz1.1a didn't seem to have the same speed issues. I don't know 
what happened since that version.

Someone once suggested that the problem lies in the way screen updates are 
performed. The thought was that everytime Mozilla updates an element on the 
screen, it updates ALL other elements. So in a loop that updates 3 sprites, 
say, Mozilla doesn't simply run through and update each of those 3 sprites 
once. When it updates sprite[1], it also does 2 and 3. Then when it updates 
sprite[2], it does 1 and 3, etc. 

I'm not sure if this is true, but it would fit with my observations. Mozilla's 
performance seems to drop extremely rapidly as more sprites are added.

Interesting observation about Opera. I haven't tested on that browser for 
quite some time. I must download the latest and have a look...
I'll throw in some comments about javascript speed stuff.. I've written some
calculation scripts with javascript before, and I've always wanted them to run
faster in firefox, but I had to use IE for faster calculations (Yeah.. I
probably should have used another programming language :p but I was building off
what someone else wrote)

One thing to note was that IE would freeze up the display whenever it was doing
the calculations while Firefox would correctly display the updates (numbers
incrementing in an input box) While it was nice to see the screen update, I
suppose it slowed things down significantly... But then this is more directly
related to Bug 230170.

Also according to http://www.macrumors.com/pages/2004/06/20040629175535.shtml
"One users' BenchJS score went from 113 seconds to 16.29 seconds from Safari
1.2.2 to 1.3 (screenshot). Meanwhile Firefox .9 scored 49.0 seconds on the same
test/hardware config (1GHz PowerBook)." I was amazed by the speed increase of
Safari. While the original speed wasn't that great, it was acceptable because it
was an early version.. but then so is Firefox kinda. Both Safari and Firefox
have potential for speed up, and it seems like apple has been able to capture it.

Btw, does anyone have a current testcase as it seems like Dadoo's original
testcase game has disappeared.
Edward: i created bug 249546 about testcase You gave.
(Reporter)

Comment 52

14 years ago
Hello,

I removed the link and the benchmark because I thought noone was caring about 
it anymore.

So here is the new link to this javascript "advanced" benchmark :  

http://perso.wanadoo.fr/avalon-games/js_benchmark/benchmark.htm
Created attachment 153387 [details]
Updated profile with current trunk

I just ran that last testcase with the current bug 230170 patch (which makes it
about 10% faster, by the way).	Short story:

Total hits:  421049

Under style reresolution:  35578
Under painting: 13154
Under reflow: 29102
Under XPTC_InvokeByIndex (all calls into gecko from JS; this includes the
"under
    reflow" part, since that all happens off the GetClientWidth call): 69237
Under nsScriptSecurityManager::CanAccess: 60579

That looks like it for the "useful" part of things (insofar as the security
manager can be considered so).	That totals 180k hits, or about 40% of total
time.  If you ignore the script security manager, we'r talking more like 27% of
total time.  The rest seems to be spent in places like:

Under XPCConvert::NativeInterface2JSObject: 21546
Under JS GC: 12594
Under jsd_FunctionCallHook: 16636
Under XPCCallContext::XPCCallContext: 18242
Under XPCNativeSet::FindMember: 1101 (not much at all!)
Under XPC_WN_Helper_NewResolve: 18258 (some overlap with the XPCCallContext
				       constructor and with FindMember here).
And more stuff all sorta scattered throughout xpconnect and JS land.

I'm going to try profiling with venkman to see what it says too...
Attachment #153387 - Attachment is patch: false
Attachment #153387 - Attachment mime type: text/plain → application/zip
Here's what venkman has to say:

27 <http://perso.wanadoo.fr/avalon-games/js_benchmark/bench-gif.htm>

  bench-gif.htm: 2500 - 1000000 milliseconds
    Function Name: scroller  (Lines 219 - 241)
    Total Calls: 644 (max recurse 0)
    Total Time: 35861.66 (min/max/avg 51.35/140.22/55.69)

    Function Name: collide  (Lines 48 - 69)
    Total Calls: 645 (max recurse 0)
    Total Time: 23984.49 (min/max/avg 31.85/120.34/37.19)

    Function Name: zorder  (Lines 116 - 124)
    Total Calls: 644 (max recurse 0)
    Total Time: 9183.66 (min/max/avg 13.39/94.17/14.26)
-------------------------------------------------------------------------------

  bench-gif.htm: 25 - 75 milliseconds
    Function Name: clicns  (Lines 165 - 174)
    Total Calls: 1 (max recurse 0)
    Total Time: 59.16 (min/max/avg 59.16/59.16/59.16)

    Function Name: movemap  (Lines 200 - 216)
    Total Calls: 1 (max recurse 0)
    Total Time: 57.56 (min/max/avg 57.56/57.56/57.56)
-------------------------------------------------------------------------------

  bench-gif.htm: 7.5 - 25 milliseconds
    Function Name: mouseMove  (Lines 129 - 142)
    Total Calls: 20 (max recurse 0)
    Total Time: 10 (min/max/avg 0.48/0.7/0.5)
-------------------------------------------------------------------------------

  bench-gif.htm: 0.75 - 2.5 milliseconds
    Function Name: bougercible  (Lines 184 - 192)
    Total Calls: 20 (max recurse 0)
    Total Time: 1.58 (min/max/avg 0.07/0.09/0.08)

-------------------------------------------------------------------------------

So the "scroller", "collide", and "zorder" functions are taking all the time
here...  Someone care to analyze them a bit and see what they're up to?

Oh, for comparison's sake Opera is about twice as fast as we are on my machine
(though it's much jerkier -- it's dropping frames left and right in this animation).

Comment 55

14 years ago
@reporter/testers: please try with a current trunk build and post your 
feedback.
Well, I've made a testcase which just uses setTimeout inside a function:
http://home.hccnet.nl/m.wargers/test/mozilla/jsbench/bencha2.htm
IE and Opera7 take a little more than 7000ms to finish the task.
Mozilla (Firefox) takes a little more than 1100ms to finish the task.

Using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040812
Firefox/0.9.1+
on a 800MHz Duron.

Comment 57

14 years ago
Okay,
now add a few moving and resizing images over a complex background. You will 
notice a significant drop in Firefox performance, while IE's performance will 
be unaffected.

Please cc me when someone actually answers the question I asked in comment 54....

Comment 59

14 years ago
Created attachment 156722 [details]
benchmark tester for setTimeout and setInterval

This testcase lets you specify the number of runs and an interval/timeout time.
You can then start the test using either setTimeout or setInterval. After
completion, it adds a short summary to a result list.

I noticed that setTimeout and setInterval seem to take longer to run on Mozilla
(at least on the latest trunk builds) than on either IE or Opera. However, I
didn't notice any difference between setTimeout("fnc()", 1) and setTimeout(fnc,
1). On my Athlon XP1800+ (on Win2K) 1000 runs with a delay of 1ms take 16.4
seconds, whereas with the latest IE and Opera versions they take 10ms. BTW, CPU
usage remained very low during those tests. Would it make sense to open a
separate bug for this?

Comment 60

14 years ago
Oops, of course my last comment should read "...whereas with the latest IE and
Opera versions they take 10 seconds", not milliseconds.

Comment 61

14 years ago
Opened bug #257454 as a result of some feedback received for comment #59. Added
dependency.
Depends on: 257454

Comment 62

14 years ago
I "assume" the 10 seconds is a result of minimum timeslice on Windows being 10ms..?
(Reporter)

Comment 63

14 years ago
I just downloaded the last firefox.
Things are worst than ever.
A simple window when draged upon the windows desk is ok, but if you only add 
some transparent gifs in it, this simple window is slow with a slower redraw.
What did change to have such a bad result ?
It seems the rendering engine has big problems with anything other than a 
static page. Every style effect like resizing IMG dynamicly has slow issue. I 
don't know if this is a firefox bug or a more vicious hidden implementation 
from microsoft to do it (I may be paranoïac I know). I have a really big 
config : 3Ghz proc with 128 nvidia 6600 card so this is a soft issue for sure.
The differece when using IE to render page is enormous.
I think if I was a standard user, i'll quit moz. This is a case of urgency.


Comment 64

14 years ago
(In reply to comment #63)
I have a really big 
> config : 3Ghz proc with 128 nvidia 6600 card so this is a soft issue for 
sure.
> The differece when using IE to render page is enormous.

I have noticed the same issue. I have found that my dhtml games perform better 
in IE on 1.3 Ghz, 128meg ram, laptop with integrated graphics than they do 
with Firefox on the 3Ghz, 1Gig ram, desktop with nvidia graphics that I use 
for testing. Its very annoying.

I think the team needs to take a step back, and look at some of the early 
(very fast) releases of phoenix. Perhaps the answer is in there somewhere.

BTW, the issue is extremely serious when a script scrolls the screen. Look at 
my www.def-logic.com/equalizer/ in IE, then try in Firefox. In IE it runs at 
24 frames per sec (and I have had it up to about 40FPS). In firefox, it runs 
at 2 frames per second.

I know the team is working on these issues, and I wait with interest to see 
how they will be solved.

Cheers,
Brent.

Comment 65

14 years ago
Hi, I have to retract my last post.
I just downloaded the latest build, and *** I am very impressed *** :)

The scrolling issue seems to have disappeared. My www.def-
logic.com/counterterror/ scrolling game runs just as well as it does in 
Internet Explorer. I had some speed consistency problems with www.def-
logic.com/replicator/ when I first played. But they seemed to go away when I 
reloaded it after trying some other games. Now it is running at perfect speed. 
In fact, all my games run at perfect speed in this build.

Thanks heaps for the work you guys are doing. This is very promising.

How long before Firefox users get this update?

Cheers, 
Brent.
(Reporter)

Comment 66

14 years ago
I would like to have this last build, I was spoking about the regular update 
that can be found on the official site. I'm happy someone was having the same 
issues with this built. In fact my investigations are that everything 
containing transparency will slow down the rendering engine, I mean 
transparent gifs on a graphical background... I 'm trying to have this built 
and will tell if better or worse. If someone push the url to me :) thanx...
(Reporter)

Comment 67

14 years ago
Found it !
Ok everything runs cool with this one.
Pfff I was really afraid that things could rest the way they were with the 
last public realise. The last public realise should be trashed away quickly to 
let this beta take its place. I'm benching it with my old javascript benchmark 
that I let at http://www.avalon-soft.com for the community use.
Shoud I mention it "thanx" of course for correcting those issues.
(Reporter)

Comment 68

13 years ago
The last official french build is getting better than the surprisingly worst previous one. The DHTML big effects like DIV scrollings are allmost comparable with Internet Explorer or Opera speed : EXCEPTING when the div scrolled has an animated gif on a inner DIV. In this case the speed is divided by 10. So this is the new issue : the gif engine rendering is slowering everything and has to be fixed.
Regards everyone and MC for all of you ^^
Daniel, please file a new bug for that (with a testcase) and mention the bug number here.
Assignee: jdunn → nobody
QA Contact: tpreston → layout

Comment 70

8 years ago
As per last coments, mark as fixed?
You need to log in before you can comment on or make changes to this bug.