Closed
Bug 603737
Opened 14 years ago
Closed 12 years ago
Speed degradation animation in FF4 beta 4 versus beta 3
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | - |
People
(Reporter: mark.trzynasty, Assigned: mstange)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3) Gecko/20100805 Firefox/4.0b3
Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3) Gecko/20100805 Firefox/4.0b3
This is the browsers speed (productivity) test for big picture animation on background or not. (With the special comparison Firefox 4 in beta versions 3 and 6).
How: count the left-to-right-to-left (full loop) div move.
div animation duration test: 30 s
system: Windows XP, 1.5 GHz
1. with background (start-background.html) - see css:
browser / move loops left-right (bigger = better):
Opera 10.61 / 24x per 30s
Opera 10.10 / 24x
Opera 10.53 / 23x
Opera 10.70 / 22x
IE6 / 20x
Firefox 3.5 / 19x
Firefox 3.68 / 19x
SeaMonkey 2.0 / 19x
Firefox 4 beta 3 / 19x (fast) <===== beta 3 ok
IE7 / 19x
IE8 / 19x
Chrome 5 / 11x
Chrome 6 / 11x
Safari 5 / 8.5x
Firefox 4 beta 6 / 4.5x (very slow!!!) <===== beta 6 gfx engine error?
In FF4b6 is no bug, IF the background is off:
2. without background (start-nobackground.html) - see css:
browser / move loops left-right (bigger = better):
Opera 10.70 / 25x
Opera 10.61 / 25x
Opera 10.53 / 25x
Opera 10.10 / 24x
IE6 / 20x
Firefox 3.5 / 19x
Firefox 3.68 / 19x
SeaMonkey 2.0 / 19x
Firefox 4 beta 3 / 19x <===== beta 3 ok
IE7 / 19x
IE8 / 19x
Chrome 5 / 12x
Chrome 6 / 12x
Firefox 4 beta 6 / 13x <===== beta 6 ok, faster - no bug
Safari 5 / 9.5x
Reproducible: Always
Steps to Reproduce:
1. Download and decompress my zip from rapidshare
2. Run start-background.html on FF 4 beta 6
3. Run start-background.html on FF 4 beta 3 and compare speed
This is a link for a mobile (portable) versions of FF4 beta 3 and 6 for test this bug:
http://downloads.sourceforge.net/portableapps/FirefoxPortableTest_4.0_Beta_3_English.paf.exe?download
http://downloads.sourceforge.net/portableapps/FirefoxPortableTest_4.0_Beta_6_English.paf.exe?download
Or this is for many languages (just change 6 to 3 in download link):
http://portableapps.com/apps/internet/firefox_portable/test
Actual Results:
Very slow moving pic ONLY on Firefox 4 beta 6.
Ok on: Firefox 4 beta 3, Opera, Chrome etc.
Expected Results:
This strange bug must be fixed very quickly.
Else the animation of HTML5 games, pictures gallery, any scroll, demonstration (like PowerPoint, slideshows like Ipad smooth pic moving) will be IMPOSSIBLE to show with a user's comfort.
This is not critical, but if you not use the GFX acceleration, very speedy processor (> 3 Ghz) or any other - this bug is very visible for big pictures in any system.
I'm a web developer and for now I suggest my clients FF 3.6 or FF 4 beta 3 or SeaMonkey 2.0, because of this bug in FF 4 beta 6.
This is a small HTML code for reproduce a bug if a rapidshare link is deactivated (in the future):
Before runnig you MUST add (create) a 2 any pictures in the same folder:
pic1-background.jpg (about 1280 x 1000 px)
pic2-photo.png (800 x 600 px), png
============================== code START:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title>Firefox 4 beta 6 Background Slow Animation Error - with background</title>
<meta name="Author" content="Lech Balcerzak">
<style type="text/css">
HTML, BODY
{
height: 100%;
padding: 0px;
margin: 0px;
background: url(pic1-background.jpg) no-repeat;
}
#pic2-photo
{
position: absolute;
width: 800px;
height: 600px;
border-width: 0px;
background: url(pic2-photo.png) no-repeat;
}
</style>
</head>
<body>
<div id="pic2-photo"></div>
<script type="text/javascript">
var ELEM = document.getElementById("pic2-photo");
var MOUSE_THIS_X = 0;
var MOUSE_THIS_Y = 0;
MouseMove_R();
function MouseMove_R()
{
MOUSE_THIS_X = MOUSE_THIS_X + 8;
ELEM.style.left = parseInt(MOUSE_THIS_X) + "px";
if (MOUSE_THIS_X >= 400)
{
delay1 = setTimeout(function()
{
MouseMove_L();
}, 1);
}
else
{
delay1 = setTimeout(function()
{
MouseMove_R();
}, 1);
}
}
function MouseMove_L()
{
MOUSE_THIS_X = MOUSE_THIS_X - 8;
ELEM.style.left = parseInt(MOUSE_THIS_X) + "px";
if (MOUSE_THIS_X <= 0)
{
delay1 = setTimeout(function()
{
MouseMove_R();
}, 1);
}
else
{
delay1 = setTimeout(function()
{
MouseMove_L();
}, 1);
}
}
</script>
</body>
</html>
============================== code END
|
Reporter | |
Comment 1•14 years ago
|
||
This is a rapidshare link with my code and pics to reproduce this bug:
http://rapidshare.com/files/424653423/FF4betaGFXSpeedTest.zip
|
||
Comment 2•14 years ago
|
||
This regressed within Beta 3 <-> 4.
|
|
||
Comment 3•14 years ago
|
||
Regressed within http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d5e211bdd793&tochange=656d99ca089c
Lots of Checkins (inluding a TM Merge).
Severity: major → normal
blocking2.0: --- → ?
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
|
|
||
Comment 4•14 years ago
|
||
Also D2D changes, etc. Does disabling D2D and/or layers affect the performance here?
|
|
||
Comment 5•14 years ago
|
||
Since I can reproduce this on WinXP, D2D/DW does not count.
I explicitly disabled accelerated Layers with layers.accelerate-none:true and the Issue is still reproducable.
I checked the Regrange against TM Branch and got:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=5f0127236f8e&tochange=b22e82ce2364
Since this includes a MC -> TM Merge with a later Date than the Range in Comment 3, TM and D2D related Checkins can be ruled out as a Cause.
Keywords: testcase
|
|
||
Comment 6•14 years ago
|
||
Ok, so just to make sure you see a 4x slowdown in the relevant range, right?
I just tried this on Mac, and the Aug 13 build (as well as Aug 12) is just as fast (about 26 back and forth trips in 30 seconds) as Aug 14 or current tip. So this seems to be Windows-specific. Presumaby graphics-related.
Changes in the range that might matter:
1) roc's units changes.
2) Markus' image-drawing changes.
3) dholbert's image refactoring.
4) The d2d checkins (yes, I know you're on XP; maybe those changed something in
that codepath after all).
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
QA Contact: general → thebes
|
||
Updated•14 years ago
|
Summary: Speed degradation animation in FF4 beta 6 versus beta 3 → Speed degradation animation in FF4 beta 4 versus beta 3
|
||
Comment 7•14 years ago
|
||
I have a vague memory of Markus' image-drawing changes introducing one known speed issue, but can't find it - Markus, do you know anything regarding that?
|
Assignee | |
Comment 8•14 years ago
|
||
Yes, bug 600476. And maybe also bug 575871, though I don't know if Boris' regression range hunting over there confirms this theory.
|
|
Reporter | |
Comment 9•14 years ago
|
||
|
|
Reporter | |
Comment 10•14 years ago
|
||
Hello,
here Lech from Poland again.
1. Question
Before net test, I have a question to Firefox experts:
How to synchronize animation 60 Hz with a screen/monitor interruption (for example in video this is a Vertical Blanc Synchro (PAL: 50 impulse per s, NTSC/Laptops: 60 Hz/default).
Is (exist) instruction in Java Script to synchronize animation with frame?
In this time I can set delay to 17 ms...
setTimeout(function()
{
// animation
}, 17);
but this is not exactly 60 Hz - so the human eye see the artefacts. I need true synchro like in other languages: Delphi, C, ASM...
Thx,
L.
2. Test v2
This is next graphic speed test - v2 - automatic. Additionally more accurate: is measuring the movement for 1 minute.
Before running - close all other progs and windows!
Results:
"Speed" - Frame Per Secod per 1 move (8 px)
"Loops" - full loop left-to-right-to-left (like in first version)
"Moved" - count each move of this div (here: each 8 px horizontally)
I hope, that final version Firefox 4 will be devoid of this strange error and equally fast as 3.6 (without GFX hardware acceleration).
Best,
Lech
p.s.
Results for few browsers (with background in Full Screen F11):
FF 4 b 3 - Speed: 47.9 fps, Loops: 28.5 x, Moved: 2874 x
FF 4 b 6 - Speed: 15.23 fps, Loops: 9 x, Moved: 914 x
|
|
||
Comment 11•14 years ago
|
||
> Is (exist) instruction in Java Script to synchronize animation with frame?
No, though I think that mozRequestAnimationFrame will do the right thing if you use it right.
|
|
||
Comment 12•14 years ago
|
||
(see http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/ for more information on that. However, if you want 60fps, you may be out of luck -- we limit paints to 50 fps, as explained at the end of that post.)
|
|
||
Comment 13•14 years ago
|
||
We changed it to 60Hz later in response to feedback.
|
|
Reporter | |
Comment 14•14 years ago
|
||
1.
> http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/
This is it probably! Even Daniel Cassidy is writing there: "this is vsync() for JavaScript". I must read many more in internet about this and try.
So, Boris and Daniel: thank you!
***
2.
>We changed it to 60Hz
Boris: Yes, max fps must be increase to 60 fps because every computer monitor working on this frequency (framerate) or multiples (for example 120 Hz if you use 3D stereoscopy-monitor). 50 Hz is good, but only in video (PAL Europe).
In this time I trace any new ideas about newest Firefox, because I'am, not only web developer but also inventor, artist and scientist (optics, programs, AI, electronics) and (my last project): "Aurelie" - Machine Translation on Neural Networks (created in Delphi :-).
For now, I try to develop an experimental website with 3D view (3d windows, with full of speedy 3d animations, 3d gadgets and 3d photos).
I think, that the browser like Firefox can be good not only for classic, static www, but also like electronic book, AI interface, animation station with full and smooth animation without Flash, web apps looks like desktop apps and many more.
Imagine you Firefox in the close future: neural comp in the pocket, screen on the air as a laser-holographic, 150" half-sphere around the user, and virtual keyboard and mouse.
***
3.
In my country now is 5:30 AM, so I have to go sleep. Good night.
Lech
|
|
||
Comment 15•14 years ago
|
||
It seems very likely that this is the same as bug 600476; if it isn't, Markus, feel free to reassign it to me.
Assignee: nobody → mstange
blocking2.0: ? → betaN+
|
||
Comment 16•14 years ago
|
||
Bug 600476 landed, so this should hopefully be better in tomorrow's nightly.
|
|
||
Comment 17•14 years ago
|
||
(In reply to comment #16)
> Bug 600476 landed, so this should hopefully be better in tomorrow's nightly.
Testing on WinXP with Build http://hg.mozilla.org/mozilla-central/rev/50eb584944aa (what is past Checkin of Bug 600476) reveals:
* Regression is gone/Speed on par with 3.6 explicitly setting layers.accelerate-none;true
* with accelerated Layers enabled (D3D9 in my Case) the Regression is still there
So presumably there's some Work for (at least) the D3D Paths left to do ....
|
||
Comment 18•14 years ago
|
||
For reference (this was with the latest nightly, so -without- bug 600476) on my system this is currently:
FF 3.6:
101 fps
61 loops
6105 moved
FF 4 latest nightly:
D2D/D3D10:
98 fps
58 loops
5890 moved
GDI/D3D9:
66 fps
39 loops
3980 moved
GDI/BasicLayers:
66 fps
39 loops
3987 moved
I'll try again with tomorrows nightly. I don't see any possibility how atleast bug 600476 could have different effects on GDI/BasicLayers and GDI/D3D9. It could certainly have different effects on D2D.
|
|
||
Updated•14 years ago
|
blocking2.0: betaN+ → -
|
|
Reporter | |
Comment 19•14 years ago
|
||
Hello,
I discovered hack that maybe help you delete source of error in FF4b6+. This hack increase speed on FF4b6 / FF4b7 / FF4b8.
FF6b6 run faster if you change global background in my code to pseudo-backgroud (semi-background in div):
============
FROM (background):
<HTML>
<style type="text/css">
HTML, BODY
{
height: 100%;
padding: 0px;
margin: 0px;
background: url(pic1-background.jpg) no-repeat;
}
... other code ...
</HTML
============
============
TO (pseudo-background):
<style type="text/css">
HTML, BODY
{
height: 100%;
padding: 0px;
margin: 0px;
overflow: hidden;
}
#pseudo_background
{
position: absolute;
left: 0px;
top: 0px;
width: 100%;
height: 100%;
padding: 0px;
margin: 0px;
background: url(pic1-background.jpg) no-repeat;
}
<body>
<div id="pseudo_background"></div>
... other code ...
</body>
============
Just delete background in html document and include backgroud to a DIV; next observe results:
FF4b3 (normal speed to compare):
Speed (fps): 48.75
Loops (x): 29
Moved (x): 2925
FF4b6 / FF4b7 / FF4b8 - regression:
FROM (backround):
Speed (fps): 15.72
Loops (x): 9
Moved (x): 943
TO (pseudo-backround in div, faster 1.46 x):
Speed (fps): 22.92
Loops (x): 13.5
Moved (x): 1375
Lech
|
||
Comment 20•13 years ago
|
||
Seems dupe for Bug 660577 or Bug 666446
|
|
||
Comment 21•12 years ago
|
||
Retested second test case in current Nightly and 3.6.28/4b3, results:
3.6.28/4b3
Speed: 99.9 fps,
Loops: 59,5 x,
Moved: 5994 x per 1 min
Nightly software
Speed: 182.5 fps,
Loops: 109 x,
Moved: 10947 x per 1 min
Nightly hwa
Speed: 239.5 fps,
Loops: 143,5 x,
Moved: 14370 x per 1 min
so seems regression gone, closing?
Flags: needinfo?(mark.trzynasty)
Whiteboard: [closeme WFM 2013-06-01]
|
|
||
Comment 22•12 years ago
|
||
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(mark.trzynasty)
Resolution: --- → WORKSFORME
Whiteboard: [closeme WFM 2013-06-01]
You need to log in
before you can comment on or make changes to this bug.
Description
•