Closed Bug 212831 Opened 22 years ago Closed 1 year ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: daniel.decourdemanche, Unassigned)

References

(
URL
)

Details

(Keywords: perf, testcase)

Attachments

(3 files, 1 obsolete file)

Non-realtime jprof profile, same 2ms timer
81.29 KB, application/x-gzip
Details
Updated profile with current trunk
430.75 KB, application/zip
Details
benchmark tester for setTimeout and setInterval
1.55 KB, text/html
Details
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.
This does not block Mozilla development.
Severity: blocker → normal
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.
URL: http://perso.wanadoo.fr/avalon-games/...
@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
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
Summary: Speed issue with DHTML bases Javascript → [DHTML] Speed issue with DHTML based Javascript (animation)
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.
Attached file Realtime jprof profile, 2ms timer (obsolete) —
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
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.
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.
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.
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
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...
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?
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...
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
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.
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....
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.
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.
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
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?
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.
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!!! :)
With this patch I get 6 seconds better !
What sort of a % improvement that does equate to? How does Moz measure against the other browsers with that 6s improvement?
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. ;)
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.
What do the latest comparison results say?
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
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
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.
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.
It would appear that I am, in fact, seeing Bug #170011 based on the source code of the URL I mentioned earlier.
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 !! ;)
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
(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 :)
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.
(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.
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
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).
@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.
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....
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?
Oops, of course my last comment should read "...whereas with the latest IE and Opera versions they take 10 seconds", not milliseconds.
Opened bug #257454 as a result of some feedback received for comment #59. Added dependency.
Depends on: 257454
I "assume" the 10 seconds is a result of minimum timeslice on Windows being 10ms..?
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.
(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.
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.
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...
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.
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
As per last coments, mark as fixed?
Severity: normal → S3

All dependencies are closed.
Closing this meta.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: