Why does a 2D animation export from Pro keep flickering?

10-09-2019 06:25 AM
New Contributor II

I have been creating animations of 2D line features though time and when I export the animations the features in the videos will randomly flicker. I have noticed this with other feature types as well. I have tried many varieties of export formats ranging from draft files, 1920x1080 to 4k at all the fps options and I have tried all of those export options on different data and different machines with different versions of ArcGIS Pro. Every single exported file inevitably at many random points in the animation flicker.

The data I have been using is stored and edited on an SDE. I have tried copying the data locally to a file geodatabase and as shape files and all the data types produce the same results.

My question is: Why is this happening, is it a bug or a setting somewhere that should be disable or enabled? How can I export an animation that does not flicker without having to export as a png sequence and edit the offending individual frames?

If anyone here can help me I would be extremely grateful!

My machine:

Type: Lenovo P51

OS: Windows 10 x64

Processor: i7-7700HQ 2.80GHz


Disks: 2 x 500GB M.2 SSD

GPU: Nvidia Quadro M1200

ArcGIS Pro version: 2.4.2

6 Replies
New Contributor III


Did you solv this or find a way around it? I have the same issue. Sometime there arbe no flickering, but sometimes there are. Seems to me it’s a bug. I am editing out the bad frames manually in Adobe Premiere. Very tedious. 

MVP Regular Contributor

Are you using a custom elevation? what fps are you exporting at? 

I get this sometimes in 3d. 

0 Kudos
New Contributor III


I am exporting 30 fps 1080x1920 and no 3D or elevation data. 

0 Kudos
New Contributor III

I also sometimes get this flicker this in both 2D and 3D animations and I finally found a solution. I was told that it is due to a problem with the rendering engine getting confused and putting layers below the surface. Yes, even in 2D.

The solution that works for me is to adjust the elevation on the flickering layer(s). Again, yes, even in 2D.

  • Open the layer's properties > Elevation
  • Set the cartographic offset to something slightly above the ground (e.g. 0.01m), or more if you are in 3D. You may also need to adjust the elevation of other layers if they disappear below this one.
New Contributor III

Since the flickering is apparently due to some "non-determinism in the z-order of the drawing of the ground surface vs. the layers painted on them" another suggested fix from an Esri dev:

  • In your layer list, select "Elevation Surfaces" > “ground” and change the color to fully transparent.
  • Then run your export again.
New Contributor III

After messing a lot with ground transparency, elevation properties (adding offsets), ground vertical exaggeration etc  - exported file is still flickering and whole animation thing in Arcgis Pro is glitchy / not robust. It is possible to avoid z-fighting for 3d layers by using Depth priority, but there no solution for 2d layers (like transparent footprints, land positions and roads on top) except for exporting things to KML and going back to Google Earth pro to record animation.
Besides the flickering, marker sizes are jerky and jumping when flying down from regional scale to local (no way to keep marker symbols consistent/same size during fly-in), layer visibility ranges simply ignored in local scene, custom projection causing "ghost labels", reference/vector tile layers are falling apart and never obey visible reference scale while exporting animation (i.e Reference/World_Boundaries_and_Places labels are unreadable/shuttered), animation export freezing application randomly with 100% GPU 0 load. Etc etc etc

Was fighting all that in Pro version 2.7.3 and 2.8

P.S. While trying to export it on laptop with different nVidia card - it behaves different, but also randomly lock up during export.
Exported animation frames have different set of glitches (white stitches dividing imagery tiles, but no flickering), so I guess all that related to nVidia drivers and handled outside of Arc. With no option to turn on software-based rendering.