Open Bug 1213513 Opened 9 years ago Updated 2 years ago

2D canvas+HTML/CSS animation demo site broken on Firefox, works great on Chrome

Categories

(Core :: DOM: Animation, defect)

defect

Tracking

()

Performance Impact low

People

(Reporter: andre, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: perf:responsiveness)

WebGL demo site broken on Firefox, works great on Chrome http://codepen.io/dropside/full/MYGKyj/
Checking out the source code, it does have the following comments section in it: <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NB: Enable 'experimental Web Platform features' in 'chrome://flags/' then restart browser - Sun and glare lighting uses mix blending modes. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --> Also Chrome page console gives the following message: "SVG's SMIL animations (<animate>, <set>, etc.) are deprecated and will be removed. Please use CSS animations or Web animations instead." In the HTML file, there's the following looking constructs: <animate attributeName="stop-color" dur="60s" values="rgba(0,19,48,0);rgba(0,19,48,0);rgba(0,19,48,0);rgba(0,19,48,0);rgba(37,32,70,.33);rgba(69,40,92,0.67);rgba(102,44,113,1);rgba(94,112,155,1);rgba(0,137,185,1);rgba(9,127,182,1);rgba(20,116,178,1);rgba(27,106,175,1);rgba(29,101,173,1);rgba(31,96,173,1);rgba(47,100,170,1);rgba(66,119,177,1);rgba(73,119,174,1);rgba(79,120,174,1);rgba(76,101,150,1);rgba(71,82,133,0.93);rgba(59,66,108,0.78);rgba(44,49,84,0.56);rgba(27,30,60,0.33);rgba(0,19,48,0.0);rgba(0,19,48,0.0)" repeatCount="indefinite" /> <animate attributeName="offset" dur="60s" values="0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0.12;0.21;0.21;0.07;0.07;0;0;0;0;" And looking at the CSS, there are some webkit-prefixed rules: -webkit-text-size-adjust: 100%; -webkit-font-smoothing: antialiased; -webkit-animation-name: stag_two; -webkit-animation-duration: 60s; -webkit-animation-iteration-count: infinite; -webkit-animation-timing-function: linear; -webkit-mask-image: -webkit-gradient(linear, left 50%, left 60%, from(rgba(0,0,0,1)), to(rgba(0,0,0,0))); mix-blend-mode: screen; Then some animation keyframe specifiers: @-webkit-keyframes stags{ 0% { fill:#0D141E;} 4% { fill:#101522;} 8% { fill:#121726;} 12% { fill:#141829;} 16% { fill:#1C1E3C;} 20% { fill:#22214F;} 24% { fill:#262262;} 28% { fill:#1D4065;} 32% { fill:#125768;} 36% { fill:#1E4553;} 40% { fill:#1E404E;} 44% { fill:#1E3B49;} 48% { fill:#1D3643;} 52% { fill:#1C313E;} 56% { fill:#1C3344;} 60% { fill:#1C3449;} 64% { fill:#1B344F;} 68% { fill:#183454;} 72% { fill:#242B4A;} 76% { fill:#2B2241;} 80% { fill:#24203C;} 84% { fill:#1D1D37;} 88% { fill:#151A32;} 92% { fill:#14192C;} 96% { fill:#111725;} 100% { fill:#0D141E;} } @-webkit-keyframes sunFocus{ 0% { -webkit-filter: blur(10px);} 16% {-webkit-filter: blur(10px);} 20% {-webkit-filter: blur(10px);} 25% {-webkit-filter: blur(5px);} 30% {-webkit-filter: blur(0px);} 80% {-webkit-filter: blur(0px);} 88% {-webkit-filter: blur(5px);} 100% {-webkit-filter: blur(10px);} } A combination of these probably is what causes the failure. The page has been written to use webkit-specific features. The resolution here might unfortunately be a wontfix because the page is relying on nonstandard features, but perhaps someone who knows about CSS can chime in and evaluate what Firefox support is like for the above webkit-specific features? Do we support any? (I recall sitting in a talk a bit more than a year ago discussing that we should add support to some webkit CSS extensions since they are so common).
Summary: WebGL demo site broken on Firefox, works great on Chrome → 2D canvas+HTML/CSS animation demo site broken on Firefox, works great on Chrome
Renaming the title, since the page does actually not use WebGL, but it is a combination of HTML/CSS animations on DOM elements, and a 2D canvas for the twinkling sprites.
Component: Graphics → DOM: Animation

AFICT, everything is working now, but the performance compared to Chrome is visibly more choppy.

Whiteboard: [qf]

There is a lot going on here:

  • Some animations are running on the main thread because the layer size is too large (bug 1100357)
  • Some animations are running on the main thread because they are being synchronized with geometric animations (at least a 'width' animation on a ::before pseudo) -- there are a few similar bugs to this where the "trello optimization" is tripping us up
  • Some of it is likely just slow because painting SVG is slow (something WebRender may one day help with)
  • Some of it is likely just because filter animations are not particularly fast (and probably should be able to run async in the future)

If we could fix the first two I think that would make a big difference (especially the second one since it affects the lens flare which is really prominent).

I think Sotaro had a look at bug 1100357 somewhat recently. I hope to look further rolling back the "trello optimization" in other bug 1506932 and bug 1512768.

Depends on: 1100357

What sotaro fixed is bug 1508522, it's for WebRender, I think on WebRender the first one is no longer a problem. (If I am wrong, sotaro will correct me)

Yes, he also looked at bug 1100357 (and bug 1324591) as part of that--I am hoping he will decide to continue looking at it :)

On my desktop, using an Nvidia 1070ti, this runs quite smoothly with D3D11. It's still not as good as Chrome, but the jank is very infrequent. However, with webrender the jank is very noticeable and with Basic composition the performance is ridiculously bad.

Here is the webrender profile: http://bit.ly/2TkFwFN

Looking at it again, this actually looks better on Firefox with D3D11 than Chrome. Even Chrome janks every 3-4 seconds.

Whiteboard: [qf] → [qf:p3:responsiveness]
Depends on: 1540906
Performance Impact: --- → P3
Whiteboard: [qf:p3:responsiveness]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.