Closed Bug 234233 Opened 16 years ago Closed 15 years ago

dhtml animation very slow when several moving elements on screen

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: brent, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: perf)

Attachments

(2 files)

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....
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: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.