Closed Bug 170702 Opened 22 years ago Closed 20 years ago

Animation Flicker (DHTML Regression)

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files)

Example DHTML which exhibits flicker
956 bytes, text/html
Details
cleaned-up testcase (valid XHTML)
948 bytes, text/html
Details
replaced innerHTML with firstChild.nodeValue
965 bytes, text/html
Details
very special loop exit condition
981 bytes, text/html
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020924

See the attached example (which incidentally is faster in mozilla than in IE!).
After the first few loops of the animation the div starts to flicker with every 
re-paint, doesn't matter how low or high the call to setTimeout is , the 
animation always flickers, works fine under Mozilla 1.1.
Incidentally, scrolling of content in iframes is also extremely choppy in this 
build, compared to the smooth scrolling I get using Mozilla 1.1

Reproducible: Always

Steps to Reproduce:
1. Open example dhtml 
2. Observe results, should start to flicker when counter get higher than 20


Actual Results:  
Unwanted flickering in animation

Expected Results:  
Smooth animation of div from top-left
attached example? :)

Doh! Good Point. Well Made.
WFM using build 2002092408, Windows 2000.
Hmm, effect is less obvious on a faster machine (500Mhz, test was with
P350,64MB) -feel free to mark WFM or resolved if you don't feel that this is a
real problem, there is a definite difference between 1.1 and the latest nightly
(on the slower machine) however, so something has affected performance.
Dupe Bug 154926 or bug 136549 ?
Ok, forget my last comment, there's no point being meek about it, there has
definitely been a regression in DHTML animation performance, it's evident on
Dell Optiplex GX1 P350, Win98 (ati rage pro graphics) - anyone with a same or
lower spec Win98 machine wish to comment?


The last working build is:
Mozilla 1.2b
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020918
Nightly Build Folder: 2002-09-18-08

The first build which exhibits flicker in animation is:
Mozilla 1.2b
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020919
Nightly Build Folder: 2002-09-19-04

kmcclusk@netscape.com has the most obvious check-in which would affect this
(timer events on win32) (sorry for singleing you out! deflect blame as you
require, I am of course just guessing :) ) - the point of that change was to fix
paint starvation issues - the example uses a 100ms setTimeout and the machine
can cope with the animation just fine in previous mozilla builds.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=09%2F18%2F2002&maxdate=09%2F19%2F2002+09%3A30&cvsroot=%2Fcvsroot

If anyone need to ask me something, best do it in the bug, I don't have email
access at work..
BTW let's not confuse people by talking about this as a "performance"
regression. Flicker is not a performance issue.
"BTW let's not confuse people by talking about this as a "performance"
regression. Flicker is not a performance issue."
Ok then, if your going to be pedantic - how about "incremented dtml suckage" ;-)
Is this a dupe of bug 154926?
I would say it's different to bug 154926 because for their testcase I don't get
the flicker that's mentioned (a least with the lastest nightly build), although
your right that they do appear to have the same symptoms and both bugs move a
div around.
Christopher, what's your graphics driver's hardware acceleration set to?  If
it's maximal, could you lower it one notch and retest?
Sure, won't be able to try it until monday. I did notice in a few other bugs
some people had varying levels of success by adjusting hardware acceleration or
setting different colour depths but since moz 1.1 worked I just assumed that the
same drawing method would be being used now as it was then. I'll give it a go..
I do seem to be suffering more than other people with some scrolling/display
bugs so maybe it's specific to my machine setup- it must be about time my
company upgraded it's PC's :)
No significant difference when display acceleration set to lower values, and no
change when colour depth set lower either. If anything there seems to be
slightly  more pronounced flicker with acceleration set lower.
Christopher, you still see this?
20020611 and NT4: looks clean...

Yes, I can still see it on nightly build 20021118(08). If no-one else is seeing
this then I imagine it's a difficult problem to solve -and indeed, if no-one
else is seeing it then I don't mind it going unfixed especially if it's just a
result of my particular machine configuration.
I have a slow system, and I cant see this. Maybe this is Windows 98 only? I am
on XP, with Pentium II, 400 Mhz
Then I also have a "slow" (?!) system. I use an Intel BX440 (350MHz PII) board
with an onboard RIVA 128ZX AGP-chipset. And I can confirm the visibility of this
bug with the reporter's attached example (see also bug #183269 and the example
there).

Indeed I also use Win98 - and the only builds with these bugs are out of the 1.2
branch. But let me give another remark (PLZ don't be confused now): At those
times when I first adopted my site to Mozilla5/Netscape6 (around Mozilla v0.99;
former versions didn't give satisfying results to me at all), I noticed, I had
to slow down certain JavaScript functions for proper running.

The concerning functions all were repeatedly self-invoking (example: have a look
at the "Articles"-section inside my site "www.telstar.int.tf", where you may see
those "curious eyeballs" following your mouse-cursor). Without slowing down the
repetition-rate of the script (vs. Netscape4 and/or MSIE) the MOUSEMOVE event
couldn't be processed with sufficient results at about 25 images/s (40ms) -- the
display (mouse-cursor and following eyeballs) was horribly jerking! So I had to
slow down the rate to its half (more than 80ms). This phenomenon looked a bit
strange to me -- anything in Mozilla seemed to run much faster than NN4 and
MSIE5 - with the exception of this peculiar mathematics-influenced 'eyeball'-script.

I don't know it exactly, but I guess those probz are highly related to this bug...?!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Blocks: 21762
Hmm - hopefully someone has an idea.
Currently there are a few bugs around dealing about the same problem.

Using latest Phoenix nightly,

I'm seeing the reported flicker in the testcase on a 2GHz Athalon with a 64meg
GeForce4 card, so this isn't just limited to lower performing machines.

Jake
Confirming this on Athlon 750 + Windows 2000 + 384 mb ram + GeForce 2.
After about 20th step it start flickering.
WFM on Linux RedHat 7.3 with old build (Mozilla 20021024).
So this is win32 only.
Can we try to further reduce the time-frame when this regression started to 
happen?

Mass-reassigning bugs.
Assignee: jst → dom_bugs
Might this be related to gfx problems we are facing (nvidia, etc.) ?

This cleaned-up version of the original testcase was my basis for examining
possible workarounds to the problem, which I could reproduce on an Athlon
XP1800+ on Win98 using build 2003042008. I'll post the additional testcases for
the workarounds shortly.
After changing all occurrences of innerHTML to firstChild.nodeValue, the
animation runs smoothly on my machine.
I can't explain why this testcase seems to help working around the problem.
When comparing the loop counter with an expression which includes at least one
of window.innerHeight, window.innerWidth, window.OuterHeight or
window.outerWidth, the animation runs smoothly on my machine. Note that
screen.height or screen.width don't seem to have the same "healing" effects.
Also, when the expression is calculated earlier so that the loop counter is
compared to a variable, the animation will still flicker.
Guesses at possible cause?
My completely unfounded suggestions would be: 
caching with respect to the retrieval of certain dom values or javascript loop
performance optimizations
is animation of on-screen atrributes double buffered in mozilla - if so then we
shouldn't be able to see the flicker even if the loop was randomly slow/fast
Just noticed that when moving the mouse pointer over the animated area, the
flickering is less obvious. This sounds a bit like bug #197341. Performance
doesn't seem to be affected in this case, though.
It sounds like forcing a reflow flush by referring to outerWidth etc ..is
stopping the flickering.
Keywords: testcase
*** Bug 203492 has been marked as a duplicate of this bug. ***
*** Bug 195919 has been marked as a duplicate of this bug. ***
I don't see this on Win2k build 20030522 (1.5GHz, 1GB RAM, some crappy 3D card).
Does this still occur for you?
Sorry, Don't have access to the machine I was testing on anymore. Hopefully
someone else who saw the problem can help you out.
someone from comment #20 or comment #21 will - I'm sure :)

i can see a little flickering with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

i don't see any flickering with FireBird 0.6.

CPU Pentium III 500Mhz, RAM 384Mb, Matrox Millenium G400
I'm the one from comment 20.  Using Firebird from 20030515 I still see
flickering in the first two testcases.  The next two, I see very little (if any)
flickering.

Jake
Similar to Comment #37 here.
First two flickers after 20th, next two dont flicker at all (or i cant see it)
I can still reproduce it on Win98.
(Mozilla 1.4-RC1 and Firebird 0.6)
(AMD XP1800+, 1GB RAM, MGA G550)
2 first examples doesn't work for me (flickering), but the last 2 work fine.

My config:
- P3 800Mhz / 128Mo Ram / Win Me / ATI RAGE LT PRO AGP 2X
- Mozilla 1.4 Build ID:2003050714 and Mozilla 1.3
- and K-meleon Version 0.7.1 Build 734 Compiled Wed Feb 12 18:21:25 2003

For other example i've post the bug #195919 (it seems to be the same problem)
Might this also be relateds to any gfx stuff?

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030706
Win88SE on XP1600+, 512 MB RAM, nVidia nForce integrated grafic.
I don´t see any of the testcases flickering, retried about 5 times.
flickering: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030706

same computer, same browser as yesterday.
Testcase 1 and 2 are flickering after having counted to about 20,
testcase 3 and 4 don´t flicker.
Closed browser and restarted browser, and got instant flicker.
Rebooted computer, and got testcase 1 + 2 flickering after having counted to 20.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030710
and same behaviour with mozilla 1.3.1 on this computer, Win98 SE.

tested with a groupmark to this bug and the 4 testcases, loaded in the background.

same as before:
loaded or reloaded one tab only, testcase 1 + 2 are flickering after about 2
seconds.
Loading as a groupmark, or reloading all tabs, flickering starts, after all
testcases have loaded (Tab 1 holds the bug, Tab 2 ..Tab 5 the testcases, tab 2
has focus)
 
This used to be WFM before, but now that I use a faster computer AMD XP 1900+,
Windows XP, 758 MB Ram, with ATI Radeon 9700 I see the flicker all the time. 
Before, when I didnt see this, i had a slower computer (Pentium III, 500 Mhz,
256 MB, Windows 2000) with NVIDIA TNT 2 graphic card. 
*** Bug 174953 has been marked as a duplicate of this bug. ***
Here is perhaps the same bug with different, but more obvious symptoms:
https://bugzilla.mozilla.org/show_bug.cgi?id=234233
It seems to be wrongly assigned to 'layout.core', but has to do with
DHTML-Animations. Although the flickering here (Bug 170702) is not very
obvious/disturbing on my system, the jerky DHTML-animations reported for Bug
234233 really look **** using mozilla (even if they are strictly W3C-DOM).
Besides, I realised, too, that the motion is smooth during the first one or two
seconds and then gets choppy (speaking of Bug 234233)... unless you constantly
move the mouse within the browser's window!
So, even if you don't consider Bug 170702 to be a serious problem, take a look
at Bug 234233, wich surely is a problem, because it forces anyone to use
ShockWave and alikes, if you want to create somewhat smooth animations that
can't be realized via moving-GIFs.

(In reply to comment #47)
> Here is perhaps the same bug with different, but more obvious symptoms

Chances are, it's not the "same" bug, since "dhtml" bugs should really be one
per site.

> It seems to be wrongly assigned to 'layout.core'

No, it's correctly assigned to layout.core.  What do you think "dhtml" is, exactly?

Please don't spam this bug with unrelated comments about unrelated testcases...
> Chances are, it's not the "same" bug, since "dhtml" bugs should really be one
per site.
I now really think they are perhaps due to the same problem. I will explain, why
I think so. But first of all I didn't want to make you angry, perhaps it's even
just due to my not so good english, I don't know. I tried to find bugs that are
like the one I just wanted to report (just not to report it twice). When I came
to this one and tried the testcases, the text did not flicker, perhaps a very,
very little bit, but it seemed Ok to me (that's why I considered this bug here
as less problematic), but then I took a look again at the dhtml-sites I posted
and, surprise, animations now where smooth! One of the testcases of one of the
several bug-reports I viewed did something to my Mozilla. Since I (then) closed
all Mozilla windows and restarted Mozilla, the animations are now again choppy
and now I even see the heavy flickering of the text in the testcases here. I
will try to find out, which page (if it was that) made my Mozilla afterwards
behave correctly, perhaps this could help to find the source of the problem.
Elsewise I won't post any more comments here, of course. I'm neither here to
spam nor for an argument.

> No, it's correctly assigned to layout.core...
Sorry, I was wrong here, thought 'layout.core' would be the layout of mozilla
and not that of the pages. So, stupid me. Sorry. It's the first time I wanted to
report a bug, was not familiar with this.
Another thing that makes me think these bugs are linked: As long as I move the
mouse the flickering is only marginal and DHTML-animations are smooth.
However, I found out what happened to me that caused the flickering go away. It
was not something special on a page, it was a page in the background (in another
tab) that just did not finish loading. As long as a page loads in the
background, there is (almost) no flickering and the animations run smoothly.
Perhaps it's even just the spinning icon that causes this effect on Mozilla's
behaviour and perhaps this is only on Win32, I don't know. I'm now using Mozilla
1.8a4 (nightly-build 2004092104), Win98SE, GeForce4, Athlon1100. That's it,
really didn't want to bother you and didn't want to spam.

I have a high end system, and this flickers very badly for me from the very
beginning.

I have noticed, however, that only the TEXT part flickers, the border seems to
be unphased. So I'm assuming this issue is all based around the .innerHTML part
of the javascript. I have done very similar scrolling content regions (but
without changing the HTML) and they never flickered like this.

System: AMD Athlon 2800XP (2.0Ghz), 1GB RAM, ATi Radeon 9800 Pro 256MB, WinXP
SP1, Firefox 0.9.2 (Mozilla 1.7 core)
Maybe when bug 157681 is fixed this will help things here too.
Blocks: 221622
Blocks: 251355
Testcases WFM using Mozilla 2004121004 Nightly on Windows XP.
I can see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+
But I can't see it anymore, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050120 Firefox/1.0+

This bug is most likely fixed by the fix for bug 244366. Marking fixed now. 
If anyone can still reproduce after a 2005-01-20 trunk build, please reopen.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
No longer blocks: 21762
Blocks: 21762
replacing innerHTML with firstChild.nodeValue prints HTML tags, so if I'm trying 
to move HTML code, it doesn't look the way it should.
workaround 2 doesn't work in IE.
Depends on: 244366
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: