ScrollView+Image.Url performance test-case

I put together this sample test-case for the team and anyone who’s interested. The scrollview displays a few (50 by default) image elements downloaded over Http.

There’s an animated loading indicator (spinner) which acts as the reload button as well. Simple.

Download from here:

My bug report:

  • on Android I get ~20fps
  • on iOS I only get ~15fps, sometimes even less
  • scrolling is jerky, especially during image download
  • if you scroll the layout during the spinning animation you can get occasional frame drops
  • ui becomes frozen sometimes for seconds on iOS

My questions:

  • how could this code be improved to get 60fps on device?:slight_smile:
  • what would be the best memory policy for image heavy apps?


Woah, that’s not 60FPS at all, is it?

Thanks for the test case, we will investigate.

Just tested with the latest (5414) and things seems changed/optimized a bit. My observations:

  • after the scrollview populated, the first tap causes huge lag but then it gets very responsive
  • async image loading/drawing doesn’t seem to have lagging effect on the scrollview now
  • after a few reloads the app gets killed with “Terminated with memory issue” on iOS
  • playing with the app, I had an unwanted system restart on Android (no logs, unfortunatelly)

Thanks for the intel. We’ve had similar reports with reboot problems (wtf?) with the preview build. We’re on it!

Just wondering if there’s any progress made on this. Digging the internals I found that TextureLoader::ByteArrayToTexture2DContentType causes the UI lags when called from HttpImageSourceImpl::HttpCallback.

This should have been mitigated by doing TextureLoader::ByteArrayToTexture2DContentType on a background-thread, and this fix will most likely be included in the 0.9.8 release. From my testing this helps a great deal. Please let us know if it doens’t help you.

Thanks Erik for the update and your efforts. I will let you know for sure.