Closed Bug 234233 Opened 21 years ago Closed 20 years ago

dhtml animation very slow when several moving elements on screen

Categories

(Core :: Layout, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: brent, Unassigned)

References

(
URL
)

Details

(Keywords: perf)

Attachments

(2 files)

Zipped-up profile data
404.09 KB, application/zip
Details
CPU load 2nd cursor covered and uncovered FF V1.0
4.57 KB, image/gif
Details
User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Greetings, I produce web-based games using dhtml and javascript. 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. 2) as more elements are added to the screen the animation slows to a crawl very quickly. 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 Thankyou for looking at this. Reproducible: Always Steps to Reproduce: 1.no specific steps. Simply load page. 2. 3. Actual Results: 1. Incorrect timeout() delays in javascript. 2. Very slow dhtml animation when several moving elements on screen esp. when image clipping and resizing is being used. Expected Results: Consistent smooth rendering of dhtml with timeout delay of 50ms per loop yielding 20 frames per second. From memory Mozilla 1.1a did not have this rendering/timing problem.
Confirming, but not limited to Firefox...
Assignee: firefox → general
Status: UNCONFIRMED → NEW
Component: General → Browser-General
Ever confirmed: true
Keywords: perf
Product: Firefox → Browser
QA Contact: general
Version: unspecified → Trunk
Are the timeout problems back again? The testcase at http://www.world-direct.com/mozilla/dhtml/timeouttest.htm shows results between 90ms and 120ms Clipping and painting are still areas to improve.
Blocks: 21762
Component: Browser-General → Layout
Assignee: general → core.layout
It still persists in Mozilla 1.8a (and 1.7.3) and I, too, recall, that some older versions of Mozilla did not have the problem. Just wanted to report it as a new Bug, when I found this posting here obviously addressing the same bug, which by the way seems to be wrongly assigned to 'core.layout'? Mozilla is not able to correctly (smoothly) display any motion generated via DHTML (JavaScript). The motion is always jerky, unless you constantly move the mouse. Strange behaviour, how come? I'm really quite sure there were earlier versions of Mozilla with better behaviour. But with mozilla 1.7.3 and 1.8a4 (at least on Win98, 1100 Athlon) motion is always choppy (unless you constantly move the mouse within the browser's window, moving the mousepointer outside the window has no effect). You can set the delay-values (using setTimeout) to 200 ms or higher and still have this effect, of course a little bit less noticable, but it shows that it is not due to CPU overload due to too short timeout values or something like this. A few examples: http://dhtmlkitchen.com/learn/js/perf/animation/setInterval.html http://www.jjam.de/JavaScript/Animation/Planetarium.html http://www.netgentry.3dmega.com/ It has something to do with the refresh rate, I suppose, which seems to be reduced when not moving the mouse. The following page blinks unless you constantly move the mouse: http://www.pyogenes.com/v2.html Any other major Browser (InternetExplorer, Opera, even Linux' Konqueror which really is not unproblematic elsewise) is able to display DHTML-animations in a smooth way... just to increase your motivation a little bit. ;-) As it seems, the problem persists on different systems (see 7th post/comment, ff): http://www.experts-exchange.com/Web/Browser_Issues/Q_21057263.html The following bug-report quite surely addresses the same problem within the mozilla sourcecode: https://bugzilla.mozilla.org/show_bug.cgi?id=170702
(In reply to comment #3) > which by the way seems to be wrongly assigned to 'core.layout'? This bug is assigned correctly. > The motion is always jerky, unless you constantly move the mouse. Sounds like a win32 event processing issue -- I don't see the mouse thing on Linux (and it's already reported as a Win32 issue in other bugs). > A few examples: Please file one bug per problematic page. Chances are, they are all slightly different provlems. > The following bug-report quite surely addresses the same problem within the > mozilla sourcecode: Chances are, it does not. There are really two separate issues reported in this bug: 1) Inconsistent update frequency. This may be related to bug 257454 and the inconsistent timer firing rate that bug produces. 2) Blanking during animation. This is probably due to the event queue being starved.... I'll profile this testcase next and attach whatever results I find.
Breakdown for this page looks like this: 253417 total hits. Of these: 48870 under nsView::Paint (called via nsWindow::UpdateIdle, ultimately). Of this, 37001 hits are under nsImageFrame::Paint, and most of the rest under SetClipRect (though there is some PopState() noise, mostly from addreffing the clip region, bug 261024). nsImageFrame::Paint spends about 10-15% of its time in XPCOM stuff (QIing mContent to nsIImageLoadingContent, getting the image off it, etc) and the rest in nsRenderingContextGTK::DrawImage (which does more XPCOM stuff, a lot of UpdateGC(), etc, plus paints the image). 4260 handling reflow events(!) 2000 or so flushing reflow because we call GenerateDragGesture for the synthetic mouse move events. Since the button is not down, why are we doing this? 15000 in general key event handling (mostly the window's key listener, etc) 145446 under running JS off a timeout. The breakdown for this last part is as follows: 87204 under XPC_WN_GetterSetter 17170 under js_LookupPropertyWithFlags rest under random JS stuff The XPC_WN_GetterSetter part breaks down as: 12389 under nsScriptSecurityManager::CanAccess 62220 under XPTC_InvokeByIndex (setting style, etc). So in summary, we spend about 25% of the total time on the page in actual Gecko processing of DOM changes, and about 25% more under painting and reflow. About 25% is spent in the JS engine, and the rest is key event handling, security checks, and minor stuff.
Attachment #159766 - Attachment is patch: false
Attachment #159766 - Attachment mime type: text/plain → application/zip
Today I experienced, that suddenly this and all the bugs that I mentioned 'vanished', without having to move the mouse constantly or anything loading in the background. The game mentioned in this bug's description then was running fine and I tried the benchmark tester from Bug 257454 and it said 10.4s!. I don't know why and how it happened and it stayed Ok, until I restarted Mozilla. After restarting Mozilla, the bugs where apparent again, but I tested all the following testcases with and without (constantly) loading a large image in the background (in another tab). I tried Mozilla (Build ID: 2004092716) and the Firefox preview release, and results were similar on my computer. Since Boris Zbarsky stated, this effect could be OS dependent: I'm using Windows98SE. A few days ago I tested my own DHTML-Animations (that are choppy on my system) on my brothers computer, running WindowsXP and latest Firefox release, and there they were smooth. Results of the testcases under the mentioned two different conditions (with and without loading an imgage in another tab) on my system: The (very large) image I used to keep loading in another tab was: http://marsrovers.jpl.nasa.gov/gallery/press/spirit/20040716a/07-MG-04-video-A190R1.jpg The JavaScript game mentioned in THIS BUG's description (www.def-logic.com/freejack/index.html): under 'normal' conditions the animation was very, very choppy, the game unplayable, with the image loading (in another tab) the animation was nice, fast and smooth. Testcases for Bug 170702: under 'normal' conditions: all testcases flickered, only the third one did not. First testcase: 10710 ms Second testcase: 10770 ms Third testcase: 10760 ms Fourth testcase: 10710 ms with image loading in another tab: No testcase showed flickering and the div moved smoothly. First testcase: 10220 ms Second testcase: 10210 ms Third testcase: 10110 ms Fourth testcase: 10210 ms Benchmark tester for setTimeout and setInterval from Bug 257454 (Loops 1000, Delay 10 ms, so result should be 10s): under 'normal' conditions: timeout test: 55.0s (1000 runs, 10ms delay, setTimeout) interval test: 55.0s (1000 runs, 10ms delay, setInterval) with image loading in another tab: timeout test: 10.8s (1000 runs, 10ms delay, setTimeout) interval test: 10.7s (1000 runs, 10ms delay, setInterval) The testcase mentioned here by Markus Hübner (http://www.world-direct.com/mozilla/dhtml/timeouttest.htm): under 'normal' conditions: 110 :: 110 270 :: 160 380 :: 110 490 :: 110 600 :: 110 710 :: 110 820 :: 110 930 :: 110 1040 :: 110 1150 :: 110 1260 :: 110 1370 :: 110 1480 :: 110 (and almost all following were 110) ...but the movement was very choppy. with image loading in another tab: 110 :: 110 220 :: 110 330 :: 110 440 :: 110 540 :: 100 600 :: 60 710 :: 110 820 :: 110 930 :: 110 1040 :: 110 1150 :: 110 1260 :: 110 1370 :: 110 1480 :: 50 (and so on: in about every 6 to 8 values one was low) ...but the movement was smooth. Am I the only one experiencing this phenomenon?
No, this is a very well known issue on Windows. The event loop is just weird somehow...
Ah, ok. It really is weird. In the testcase http://www.world-direct.com/mozilla/dhtml/timeouttest.htm it is funny to see, that the delays have consistent, but slightly to high values while this happens (while animation is choppy). Almost every timeout took exactly 110ms instead of 100ms, as it should have been. But with an image loading, when the animation runs smooth, these values are inconsistent, but summed up and taken the average value, are absolutely perfect (there are 51 values, summed up they were 5100ms, average 100ms, exactly what it should be!). I'm too novice in programming to have any idea on this, but perhaps someone else has... Besides, the choppyness of the animation looks like as if a 'display rate' differs from timeout firing rate, causing an interference like a bad adjusted 9mm film projector does, ommiting or doubling frames to 'keep pace' (there combined with jumping effects that you don't have with digital media, of course). I saw within my own DHTML animations that some 'frames' stay too long, but others are definitely omitted. Assumed that the display rate resembled the pattern (all in ms) 110 110 100 60 110 110 110 110 110 110 110 50... (i.e. the values I got when animation was smooth) and the timeout firing rate resembled the pattern 110 110 110 110 110 110 110 110 110 110 110 110... (i.e. the values I got under 'normal' conditions) that would clearly explain such interference effects. Are there two independend threads, one for the timeouts and another one handing over the timeout triggered changes to the graphics processor for instance, and both are only synchronous while moving the mouse or loading activity? Otherwise, even with somehow inconsistent timeout firing rate, some frames would look like doubled, because they stay too long, there wouldn't be any 'frames' of the animation omitted on a quite regular basis. Just food for thought, I myself am not familiar with Mozilla's source code!
(In reply to comment #9) > Besides, the choppyness of the animation looks like as if a 'display rate' > differs from timeout firing rate, causing an interference like a bad adjusted > 9mm film projector does, ommiting or doubling frames to 'keep pace' That's at least in part what's happening, yes. See comments in bug 257454 and the code referenced therein. > Are there two independend threads, one for the timeouts and another one > handing over the timeout triggered changes to the graphics processor Yes. Again, see bug 257454 and code referenced therein. > and both are only synchronous while moving the mouse or loading activity? That's a possibility, yes. Someone with a Windows system would need to test what the Windows event loop is doing. In any case, I see issues on this testcase without the dubious benefit of the Windows event loop (which means loading images or moving mice do not affect things any for me).
I have no reason to doubt that. So, there are indeed different causes for similar symptoms here, or the Win32 (and/or hardware dependend) problem just adds a lot to it and hence makes it worse, did you test the game mentioned in the bug description, is it playable on Linux? On my Win98 system even the animation of that jumping guy on the initial game screen is a complete mess. However, one should really carefully distinguish between feedback from users with different systems here or you will all get mad. ;-) And besides, thanks for spending a lot of time in developing Mozilla and thanks for having patience with me, I think.
> is it playable on Linux? Only very marginally (with a bit of practice I managed to play for 5-6 minutes or so before getting caught by the robot things). > However, one should really carefully distinguish between feedback from users > with different systems here Indeed. I have a P3-733, with a Radeon 9000 video card. I doubt anyone else is testing with a slower computer. ;)
(This comment refers to the Win32-event-loop-issue) Perhaps of interest, perhaps not: Just tested with an older version of Mozilla (v1.7). Flickering (BUG 170702) was the same compared with newest nightly build (v1.8a5,ID2004101706), but DHMTL-Animation was at least smooth, while nevertheless too slow and faster when constantly moving the mouse.
I have written a new game, which helps serve as a test for this bug. www.def-logic.com/replicator/replicator.html Having spoken to some people on a Firefox forum, I decided to try some experiments. The game currently contains all the animation for each sprite in a single gifs. The script then clips to the correct part of the gif when needed thus animating the sprite. The latest FF build gives really choppy results--the image often appears in the wrong place before suddenly jumping to where it needs to be. This effect makes me think that the browser is re-drawing elements each time a change is made, rather than waiting to update them all at once when the setTimeout is called. The reason I think this is because after clipping the image, the script quickly recalculates its x,y position to give the illusion that the sprite is in the same place. Then a timeout is called. We should never see the sprite clipped before it is moved. I'm sure none of that makes sense. Its hard to explain. Anyway, the game has a background (only 4k). When I removed the background, performance improved dramatically. Almost as good as IE. I expected a small improvement, but not that much. So perhaps there is also an issue with repainting background. I hope this makes sense. I think it is important to improve the dhtml performance of Moz, since it seems to be one of the few areas left that IE is still better. Cheers, Brent.
> The latest FF build gives really choppy results Is "latest" 1.0 here? Or trunk? If the former, could you test the latter?
The Trunk gives the choppy results. FF 1.0 seems to behave correctly (just really slow). BTW, I've just been looking at the "golden build" -- Phoenix 0.4 2002-11-14. It is very fast at dhtml animation. Much much much faster and smoother than Firefox 1.0. The www.def-logic.com/replicator/replicator.html runs just as fast as it does in IE. I'm not sure if that's helpful, Cheers, Brent.
I've filed bug 277653, for the "sometimes in the wrong place appearing" problem, mentioned in comment 14. I suspect it is a bug that is not visible on all platforms.
Just in case someone missed the discussion on mozillazine's forum: I think I have the same problem as Brent ("unsmooth" movements), maybe less apparent. I attached a screendump from my system monitor, which could help explaining the problem. It is important to test with at least 2 moving objects, one alone behaves OK! It is even sufficient to cover the second moving object (here: cursor made of an empty DIV) with another window! That indicates to me that it must have to do with windows' GDI drawing strategy or message handling. (Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0) my testcases: http://vorab.magnalox.net/log/no.php?lid=10207 (transparent GIF over transparent PNG + moving DIV, choppy) http://vorab.magnalox.net/log/no.php?lid=10227 (the same, but PNG is not transparent, -> smooth) With Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 it was OK.
Comment on attachment 170763 [details] CPU load 2nd cursor covered and uncovered FF V1.0 uups, bugzilla sort of hung when uploading....
Depends on: 277653
Note to self -- the no-background version of the replicator game is at http://www.def-logic.com/replicator/nobgtest.html
This may be a red-herring, but I installed FF 1.0 on my old win98 box. I then tried the Replicator game. It ran at virtually the same speed as Internet Explorer (i.e. nice and fast). So FF 1.0 dhtml performs better on win98 than winxp. I'm not sure if this is a relevant observation--but I thought it was worth mentioning, nonetheless. Brent.
Okay, I've been experimenting to try to fix the speed issue in my games. I have optimized all the images in my games. Optimizing the background images (obviously) has made a visible difference. I have reduced the palette to 32 colors in my backgrounds in Freejack http://www.def- logic.com/freejack/freejack.html and the speed has improved. You can still see the slow down effect, and it is not as consistent speed as IE, but it is not as bad as before. In Replicator http://www.def-logic.com/replicator/replicator.html I reduced the palette in all images. The backgrounds only had about 8 colors, but I've reduced them to 4. I've also reduced the palette in the sprites. This has made a big difference. The game starts off at quite a good speed--almost as good as IE. It slows down after a couple of levels, when there are many sprites moving around--so the effect can still be observed and tested. I hope these comments are worthwhile.
maybe another fish, but I believe not: 1) If I open on magnalox a "save as" dialog, the timer events seem to queue up in the background, until the (modal) dialogbox is closed. Then FF seems to handle all the queued events one after another very smooth and fast. This indicates again, that FF doesn't have a performance problem here, but takes "artificial" breaks. This also confirms the obeservation, that even when the display is choppy, the CPU load doesn't reach 100% 2) The problem occurs also on 3+GHz HW, on moox M3 builds and afaik on the latest trunk build, another hint in the same direction Clearly a quirk in FFs interaction with the OS, not a true performance problem. Brent: I can confirm Your observation. Maybe we should switch to black and white when finding a recent version of FF ;) All I miss now is the pterodactyl and the lava in Your game...
Note that fixing bug 244366 made this a lot smoother...
Depends on: 244366
(In reply to comment #25) I have been testing the FF trunk build 21 January 2005. I think things are looking pretty good. One noticeable improvement in my games is that the score no longer flickers when that layer is being rewritten. In earlier builds, the digits in the score layer always flickered when the layer was rewritten with a score update. Great improvement here :) I tested with Replicator. It seems generally faster. It slows down about level 3 or 4 when there are quite a few moving elements. This improvement may be partly due to my optimizing the palette in the game. The jumping problem has gone away in the image clipping, so that is (perhaps) also helping with general performance. Testing with freejack: http://www.def-logic.com/freejack/freejack.html and Amenra: http://www.def-logic.com/amenra/amenra.html seemed to indicate an improvement in performance. I noticed that in Amenra, the animation seems to skip frames occasionally. It looks like the screen is not being updated on every timeout. So the result is jerky animation. I'm uncertain why this is happening. There are not many sprites in this game, so its kind of weird. I hope I explained that observation accurately. It will be obvious what I mean for anyone who tests Amenra with the 21 Jan build. Cheers, Brent.
I am hesitating to post this, but it is what I observed: I just tested a couple of builds today, here are my results: CPU load version 97% (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050121 Firefox/1.0+ 98% (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050117 Firefox/1.0+ 97% (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050104 Firefox/1.0+ 13-60% (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041109 Firefox/1.0 (MOOX M3) 13-60% (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0 7-65% (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 9-62% (Windows; U; Windows NT 5.1; de-DE; rv:1.7) Gecko/20040803 Firefox/0.9.3 The veterans 3% (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 3% IE V6 6.0.2900.2180.xp_sp2 All this on a 2.2GHz P4 1GB Ti4200 HW. I never had the flickering problem bug 244366 bases on, but I am not clipping images dynamically. The newer builds are heading in the wrong direction for my problem, it didn't get any smoother. Even worse, I expect on a weaker HW the problem would be even more apparent. and: my cover-the-second-cursor trick doesn't work anymore. Hmmmm
Brent, I think the "jerkiness" appears already with the second moved object, what in my case is simply an empty DIV, no image, no clipping. My tests indicated that there is no big difference between 2 and 7 moving objects. So if You left the scientist alone without snakes and pharaos, it would run perfect ;) Amenra runs smooth on my HW, Gecko/20041108 (=V1.0), just to make the confusion perfect. Only when using the arrow-keys, the scen scrolls horizontally, but that seems to be unrelated. Maybe a STYLE="overflow:hidden" somewhere in the framesdefinition could help, just a thought.
ana_nas@hotmail.com, it sounds like you're seeing something quite different from what this bug was filed on. Could you please file a new bug and cc me on it? In particular, if you're seeing performance worse than Firefox 1.0 I'm very interested in your testcase -- most DHTML has gotten about 40% faster since 1.0. Brent, I just tried the Amenra game in my Linux build, and I see Mozilla using about 10% of the CPU time when it's being really laggy. The X server is using 90%. A profile shows that we're spending a lot of time scaling images. Does this game use images that are being shown at something other than their default size? Painting such takes a lot longer... Again, it may be worth it to file a separate bug on that problem.
Actually, the pages mentioned in comment 19 already have a bug filed on them -- bug 277044 and its dependencies. Note that those bugs already have information on when things broke, how much they slowed down, and what patches caused the slowdowns, so please refrain from commenting on them unless your comment is a specific suggestion on how to change Mozilla code to improve performance there.
(In reply to comment #29) > Brent, ... A profile shows that we're spending a lot of time scaling images. Does > this game use images that are being shown at something other than their default > size? There is one image in the game that is being resized. When the player launches a rope, it is a small gif 1x1, which has its height resized as the rope grows to reach the next platform. Interestingly, Freejack also has resized images. When the player releases the trapped creatures, the ice shatter effect is comprised of 9 images which are rapidly resized down to 1x1 before disappearing.
But are there images which, while not being resized, are not being painted at their default size? They could be constantly painted at the same size, as long as it's not the default size.
(In reply to comment #32) > But are there images which, while not being resized, are not being painted at > their default size? They could be constantly painted at the same size, as long > as it's not the default size. There shouldn't be--unless there is a bug in my script :) I'll go back and double check. I'll let you know...
I just had a quick look at the script. The only image on screen that is not its original size is the rope. It may be worth noting that when the page loads, I preload all images. These are put on screen in the top-left corner at size 2x2 (just so I can monitor preload with a modem). When the page load is complete, I shift these temporary preloaded images to -1000,0. I don't know if that would have an effect on page speed since they are hidden off screen. Anyway, I removed the preload and tried the game again. There was no visible performance improvement. Just to satisfy my curiousity...would having images hidden at -1000,0 at their incorrect size have any effect on performance? I'm guessing not... Cheers,
Hmm... I rechecked, and we're not actually scaling an image, just drawing one that has opacity. I'm really not sure why this takes so long, but it sounds like a separate bug from the original problem reported in this bug.
That is strange. I am not altering the opacity of images in that game. All images are gifs with transparency enabled, of course. Is that what you mean?
Yeah, I mean an image in which not all pixels are opaque (which is not quite what I said the first time -- I misspoke).
Since image clipping uses transparency to hide the clipped area (I think-- correct me if I'm wrong), I tried a different method of animation. Rather than image clipping, I put the image in a small DIV and then moved it around to the correct position to yield the same effect. This did not improve performance. So the transparency issue is probably not related to the image clipping. Rather, it could be related to the transparency being used in the gifs. Obvious, I guess.
I was thinking about the earlier comment on rescaled images. Then I noticed that the build I'm looking at (21 January 2005) resizes the main background image on my game page when I resize the window. This feature seems to make the image fit exactly to the window. Is this a new feature? The image in the background is exactly the same size as the frame the game sits in, but I'm wondering if the browser is doing some sort of a resize to that image anyway. This could explain your observations, Boris, that a lot of time is spent on a rescaled image.
(In reply to comment #39) > I was thinking about the earlier comment on rescaled images. Then I noticed > that the build I'm looking at (21 January 2005) resizes the main background > image on my game page when I resize the window. This feature seems to make the > image fit exactly to the window. Is this a new feature? :-) No, I think it's a bug. I filed bug 279579 for this.
I have just tried the latest build and have to congratulate the team. There has been a remarkable improvement in dhtml animation of my games. 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. Cheers, Brent.
So regarding comment 41, I think this can be marked WFM? I have the same observation as comment 41, and if I remember correctly, things got smoother here when bug 284716 got fixed.
Confirmed, marking WFM.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: