Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

iPhone 6 animation performance cut in half #3005

Closed
1ec5 opened this issue Nov 11, 2015 · 6 comments
Closed

iPhone 6 animation performance cut in half #3005

1ec5 opened this issue Nov 11, 2015 · 6 comments
Assignees
Labels
iOS Mapbox Maps SDK for iOS performance Speed, stability, CPU usage, memory usage, or power usage
Milestone

Comments

@1ec5
Copy link
Contributor

1ec5 commented Nov 11, 2015

To state the obvious, #2922 cuts the maximum framerate down from 60fps to 30fps. Prior to #2922, MGLMapView would pan smoothly at 60fps (as confirmed by Xcode) on my iPhone 6 running iOS 9.1. Now it maxes out at 30fps, causing every animation to be choppy to an extent that’s difficult to ignore. (An MGLTargetFrameInterval of 1 unsurprisingly feels great.) Perhaps 30fps is beneficial for the iPod touch @adam-mapbox was testing on, but that should not come at the cost of performance on more current or more powerful hardware, where there is a greater expectation of smooth animations.

/cc @adam-mapbox @incanus @friedbunny @jfirebaugh

@1ec5 1ec5 added iOS Mapbox Maps SDK for iOS performance Speed, stability, CPU usage, memory usage, or power usage labels Nov 11, 2015
@1ec5 1ec5 added this to the ios-v3.0.0 milestone Nov 11, 2015
@incanus
Copy link
Contributor

incanus commented Nov 11, 2015

Maybe we can take a naive first cut at dividing devices into two camps — lower-end and higher-end — and choosing 30 or 60 as a result. Lower-end would probably include:

  • Both iPod touch generations
  • iPad <= 3
  • iPad mini <= 2
  • iPhone <= 5

Something like that?

@adam-mapbox
Copy link
Contributor

We can also try just making it 60 fps. The essence of the fix is to do
things on a regular basis, not necessarily what exactly that basis is. It
might be "good enough", even on slower devices. I can take a look at this.

A better fix would be to do what Justin suggested.

On Wed, Nov 11, 2015 at 3:07 PM, Justin R. Miller notifications@github.com
wrote:

Maybe we can take a naive first cut at dividing devices into two camps
— lower-end and higher-end — and choosing 30 or 60 as a result. Lower-end
would probably include:

  • Both iPod touch generations
  • iPad <= 3
  • iPad mini <= 2
  • iPhone <= 5

Something like that?


Reply to this email directly or view it on GitHub
#3005 (comment)
.

@1ec5
Copy link
Contributor Author

1ec5 commented Nov 11, 2015

I’ve been playing around with MGLTargetFrameInterval set to 1 all day on the aforesaid iPhone 6, and it feels great. Let’s treat 60fps as the default, then blacklist devices that are known to perform poorly, such as iPod touch.

@adam-mapbox
Copy link
Contributor

Sure, sounds good. I'd like to do a little bit of testing on my own time
about this, but I think this should work for now.

On Wed, Nov 11, 2015 at 3:45 PM, Minh Nguyễn notifications@github.com
wrote:

I’ve been playing around with MGLTargetFrameInterval set to 1 all day on
the aforesaid iPhone 6, and it feels great. Let’s treat 60fps as the
default, then blacklist devices that are known to perform poorly, such as
iPod touch.


Reply to this email directly or view it on GitHub
#3005 (comment)
.

@1ec5 1ec5 self-assigned this Nov 12, 2015
1ec5 added a commit that referenced this issue Nov 12, 2015
@1ec5 1ec5 removed the in progress label Nov 12, 2015
@adam-mapbox
Copy link
Contributor

@1ec5 I went ahead and did some testing on this on the iPod touch, and it's going to be totally fine on all devices. As I suspected, it's the act of doing things on a regular tick that helps the framerate's visible appearance, not so much when the tick arrives. So even if the device can't quite keep up, it still is visually pleasing.

@1ec5
Copy link
Contributor Author

1ec5 commented Nov 13, 2015

🎉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
iOS Mapbox Maps SDK for iOS performance Speed, stability, CPU usage, memory usage, or power usage
Projects
None yet
Development

No branches or pull requests

3 participants