Closed Bug 170702 Opened 17 years ago Closed 15 years ago
Animation Flicker (DHTML Regression)
956 bytes, text/html
948 bytes, text/html
965 bytes, text/html
981 bytes, text/html
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.
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 email@example.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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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.
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.
*** 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.
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.
Maybe when bug 157681 is fixed this will help things here too.
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: 15 years ago
Resolution: --- → FIXED
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.
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.