Apparent Limitation to Number of Onscreen Animated Elements?

Issue #8938930 • Assigned to Rick J.


Jonathan S.
Sep 15, 2016
This issue is public.
Found in
  • Microsoft Edge
Found in build #
Reported by 3 people

Sign in to watch or report this issue.

Steps to reproduce

One of Ana Tudor’s recent CodePen’s results in many on-screen animated elements. In Microsoft Edge, the viewport simply goes black. Resizing the viewport will cause intermittent paints of the animated elements.

Reducing the total number of onscreen animated elements resolves the issue (or rather, avoids the issue). The attachment zip contains two HTML files: one with many animated elements (which doesn’t pain), and the other with fewer (which paints).


Comments and activity

  • Tested on Windows builds 10586.589, 14393.187 and 14926.1000 and in all cases the breaking point appears to be the 99th "rotor". 98 display fine. Perhaps also worth noting, the tests were performed on 3 different machine configurations, with varying amounts of RAM, CPU and GPU. All displayed the same phenomenon of breaking when the 99th “rotor” was added.

  • Another curiosity: removing the “background-position” property from any two @keyframe c… declarations causes the 99-rotor scenario to work again–although very choppy–but only after resizing the window. Removing subsequent “background-position” properties from additional @keyframe’s causes the animation to move progressively smoother.

  • Microsoft Edge Team

    Changed Assigned To to “Rick J.”

  • I can recreate the problem in Ana’s pen. I can also confirm that the cut-off point is approx 100 rotor-tiles, but it depends on how they are distributed: Edge can handle higher total number of elements if there are more bars with fewer tiles per bar.

    For whatever it’s worth, I created a series of simpler CSS 3D stress tests which don’t cause the complete lack of paint (although they will spin your fan and cause the framerate to crunch to near-zero):

    Important distinction in those is that these are animating transforms only; the individual tiles do not need to be re-painted between frames.

    I do, however, start to see missed paints with this one, although it isn’t as complete as with Ana’s demo; it goes black for a few seconds and then tries again:

    Removing either the nested transforms or the 100s of keyframes turns it back it to a plain old bad framerate animation, even after increasing to 500*9 elements:

    Given this, maybe the problem is that the compositor doing the 3D transforms isn’t waiting for the painting engine to finish? Or they are getting out of sync one way or another, and the compositor is working with blank layers that the painter isn’t finished with.

You need to sign in to your Microsoft account to add a comment.

Sign in