1

As noted in this answer, fading edges in ScrollViews can be slow. I want to know, why?

"Using fading edges may introduce noticeable performance degradations and should be used only when required by the application's visual design. To request fading edges with API level 14 and above, use the android:requiresFadingEdge attribute instead"

http://developer.android.com/reference/android/R.attr.html#fadingEdge

My interest is motivated by two things:

  • Wanting to use fading edges to provide a visual cue to the user
  • Noticing /extreme/ performance loss on a PowerVR SGX 544 Galaxy S4 when using fading edges. (dropping from 20-30 fps to 0.2 fps), while not-seeing that performance loss on other GPUs (e.g. Adreno 320 HTC One)

I thought that maybe fading edges were implemented as separate layers in SurfaceFlinger and that they triggered GLES compositing over hardware compositing, but that is not so, according to this comment

Community
  • 1
  • 1
nmr
  • 16,625
  • 10
  • 53
  • 67
  • I can't answer the Why, but can you see if it performs better when setting `android:hardwareAccelerated="true"`? – josephus Jun 19 '14 at 01:39
  • 1
    Romain Guy explains briefly [here](http://www.curious-creature.org/2008/12/22/why-is-my-list-black-an-android-optimization/). It means more reads, writes and draws. – alex Jun 19 '14 at 02:01
  • Yup, see romainguy's article. Use of edge-fading is discouraged because of the performance issues. – fadden Jun 19 '14 at 14:53
  • Romain's post is helpful background, but it is not an explanation for the discrepancy on KitKat devices. (It's from 2008, for one thing). The View hierarchy is drawn with GLES now (right?), and a handful of draws with blending enabled should /not/ slow it down by a factor of 100~. I wonder if maybe, for some reason, the TouchWiz 4.4 build for the S4 forces the layer into CPU drawing mode (by calling lockCanvas or something). FWIW, my question is regarding ScrollView, not ListView, which is the topic of Romain's post. @josephus HW acceleration is already enabled (target SDK = 19). – nmr Jun 19 '14 at 19:04

1 Answers1

1

Update: https://developers.google.com/events/io/sessions/325418001 About 30 minutes in Romain mentions how fading edges are implemented and why the implementation makes them slow.

I am coming to believe that the note in the documentation is misleading in today's context, and that I stumbled upon an unrelated pathologically bad situation. I have found that normally fading edges are not slow. The linked post informs us of Romain's perspective on the feature, although the note wasn't added until Sept. 2011.

Different systems use different drawing paths, different GPU driver paths, and different GPU hardware paths for doing the actual rendering of the fading edges. I think that due to the complexity of the scene I was trying to display I crossed a limit of my particular phone.

This commit introduced the note. It was made in the lead up to Android 4.0, while 3.2.x series were still being released. I remember the Xoom being a bit of a slow device, and I imagine that a few fading edges (easily made on by default) could have dragged it to a crawl. That seems like a good rationale to make the change and introduce the note.

nmr
  • 16,625
  • 10
  • 53
  • 67