Any interaction with the screen locks animation
up vote
0
down vote
favorite
I have a UIView that sets a timer and each firing it generates a UIImage on a background queue (priority .userInitiated), and when finished (measured to take between 1-2 milliseconds, it pushes to the main queue and updates a UIImageView's image.
This creates a smooth animation effect (e.g. if the Timer is configured to fire 30 times per second). Touching the screen however either slows down or completely shuts down the updating. I removed my overrides of touchesBegan,Moved,Ended and any GestureRecognizers to ensure that I wasn't doing anything expensive. Simply touching the screen (especially dragging quickly) prevents the UI updating.
I watched this and googled as many SO posts as I can but I'm completely stuck on this.
Here is a reproduction of the problem. Run the app and it will display a stripped down rendering of a basic project. From there, you can drag/touch the screen and notice the frames will either slow down to a crawl or completely stop.
Github Repro
ios uiimageview core-graphics
asked Nov 5 at 3:48
Alex Bollbach
1,305736
|
show 3 more comments
up vote
0
down vote
favorite
I have a UIView that sets a timer and each firing it generates a UIImage on a background queue (priority .userInitiated), and when finished (measured to take between 1-2 milliseconds, it pushes to the main queue and updates a UIImageView's image.
This creates a smooth animation effect (e.g. if the Timer is configured to fire 30 times per second). Touching the screen however either slows down or completely shuts down the updating. I removed my overrides of touchesBegan,Moved,Ended and any GestureRecognizers to ensure that I wasn't doing anything expensive. Simply touching the screen (especially dragging quickly) prevents the UI updating.
I watched this and googled as many SO posts as I can but I'm completely stuck on this.
Here is a reproduction of the problem. Run the app and it will display a stripped down rendering of a basic project. From there, you can drag/touch the screen and notice the frames will either slow down to a crawl or completely stop.
Github Repro
ios uiimageview core-graphics
asked Nov 5 at 3:48
Alex Bollbach
1,305736
Personally I'd use aCADisplayLink, but you need to configure it so it's not affected by scrolling
– MadProgrammer
Nov 5 at 3:50
sure, but i'm still running the intensive processing on a background queue and simply updating the UIImageView's image on the main queue. apple even suggests one can use both a Timer and a DisplayLink to do real time animating like this. I'll try substitution a DisplayLink but using a Timer specifically should not be the bottleneck.
– Alex Bollbach
Nov 5 at 3:56
As I understand it, both (by default)CADisplayLinkandTimerrun on the mainrunLoop, so any UI interaction could "stall" them - I might be over simplifying this though
– MadProgrammer
Nov 5 at 3:58
well, something relevant here is that I added a print statement in the line that pushes to the main queue and updates the UIImageView. when i start dragging, its stilled fired. So the Timer keeps firing, the processing is succeeding while I'm dragging, I just don't see the results. So the problem appears to be "downstream" of the timer firing and rendering.
– Alex Bollbach
Nov 5 at 4:00
Possibly because the "paint" cycles are suspended? I was told in passing aboutTimerrunning on the main run loop and how would be affected by scrolling :/
– MadProgrammer
Nov 5 at 4:02
|
show 3 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a UIView that sets a timer and each firing it generates a UIImage on a background queue (priority .userInitiated), and when finished (measured to take between 1-2 milliseconds, it pushes to the main queue and updates a UIImageView's image.
This creates a smooth animation effect (e.g. if the Timer is configured to fire 30 times per second). Touching the screen however either slows down or completely shuts down the updating. I removed my overrides of touchesBegan,Moved,Ended and any GestureRecognizers to ensure that I wasn't doing anything expensive. Simply touching the screen (especially dragging quickly) prevents the UI updating.
I watched this and googled as many SO posts as I can but I'm completely stuck on this.
Here is a reproduction of the problem. Run the app and it will display a stripped down rendering of a basic project. From there, you can drag/touch the screen and notice the frames will either slow down to a crawl or completely stop.
Github Repro
ios uiimageview core-graphics
asked Nov 5 at 3:48
Alex Bollbach
1,305736
I have a UIView that sets a timer and each firing it generates a UIImage on a background queue (priority .userInitiated), and when finished (measured to take between 1-2 milliseconds, it pushes to the main queue and updates a UIImageView's image.
This creates a smooth animation effect (e.g. if the Timer is configured to fire 30 times per second). Touching the screen however either slows down or completely shuts down the updating. I removed my overrides of touchesBegan,Moved,Ended and any GestureRecognizers to ensure that I wasn't doing anything expensive. Simply touching the screen (especially dragging quickly) prevents the UI updating.
I watched this and googled as many SO posts as I can but I'm completely stuck on this.
Here is a reproduction of the problem. Run the app and it will display a stripped down rendering of a basic project. From there, you can drag/touch the screen and notice the frames will either slow down to a crawl or completely stop.
Github Repro
ios uiimageview core-graphics
ios uiimageview core-graphics
asked Nov 5 at 3:48
Alex Bollbach
1,305736
asked Nov 5 at 3:48
Alex Bollbach
1,305736
edited Nov 5 at 6:38
asked Nov 5 at 3:48
Alex Bollbach
1,305736
asked Nov 5 at 3:48
Alex Bollbach
1,305736
asked Nov 5 at 3:48
Alex Bollbach
1,305736
1,305736
Personally I'd use aCADisplayLink, but you need to configure it so it's not affected by scrolling
– MadProgrammer
Nov 5 at 3:50
sure, but i'm still running the intensive processing on a background queue and simply updating the UIImageView's image on the main queue. apple even suggests one can use both a Timer and a DisplayLink to do real time animating like this. I'll try substitution a DisplayLink but using a Timer specifically should not be the bottleneck.
– Alex Bollbach
Nov 5 at 3:56
As I understand it, both (by default)CADisplayLinkandTimerrun on the mainrunLoop, so any UI interaction could "stall" them - I might be over simplifying this though
– MadProgrammer
Nov 5 at 3:58
well, something relevant here is that I added a print statement in the line that pushes to the main queue and updates the UIImageView. when i start dragging, its stilled fired. So the Timer keeps firing, the processing is succeeding while I'm dragging, I just don't see the results. So the problem appears to be "downstream" of the timer firing and rendering.
– Alex Bollbach
Nov 5 at 4:00
Possibly because the "paint" cycles are suspended? I was told in passing aboutTimerrunning on the main run loop and how would be affected by scrolling :/
– MadProgrammer
Nov 5 at 4:02
|
show 3 more comments
Personally I'd use aCADisplayLink, but you need to configure it so it's not affected by scrolling
– MadProgrammer
Nov 5 at 3:50
sure, but i'm still running the intensive processing on a background queue and simply updating the UIImageView's image on the main queue. apple even suggests one can use both a Timer and a DisplayLink to do real time animating like this. I'll try substitution a DisplayLink but using a Timer specifically should not be the bottleneck.
– Alex Bollbach
Nov 5 at 3:56
As I understand it, both (by default)CADisplayLinkandTimerrun on the mainrunLoop, so any UI interaction could "stall" them - I might be over simplifying this though
– MadProgrammer
Nov 5 at 3:58
well, something relevant here is that I added a print statement in the line that pushes to the main queue and updates the UIImageView. when i start dragging, its stilled fired. So the Timer keeps firing, the processing is succeeding while I'm dragging, I just don't see the results. So the problem appears to be "downstream" of the timer firing and rendering.
– Alex Bollbach
Nov 5 at 4:00
Possibly because the "paint" cycles are suspended? I was told in passing aboutTimerrunning on the main run loop and how would be affected by scrolling :/
– MadProgrammer
Nov 5 at 4:02
Personally I'd use a
CADisplayLink, but you need to configure it so it's not affected by scrolling– MadProgrammer
Nov 5 at 3:50
Personally I'd use a
CADisplayLink, but you need to configure it so it's not affected by scrolling– MadProgrammer
Nov 5 at 3:50
sure, but i'm still running the intensive processing on a background queue and simply updating the UIImageView's image on the main queue. apple even suggests one can use both a Timer and a DisplayLink to do real time animating like this. I'll try substitution a DisplayLink but using a Timer specifically should not be the bottleneck.
– Alex Bollbach
Nov 5 at 3:56
sure, but i'm still running the intensive processing on a background queue and simply updating the UIImageView's image on the main queue. apple even suggests one can use both a Timer and a DisplayLink to do real time animating like this. I'll try substitution a DisplayLink but using a Timer specifically should not be the bottleneck.
– Alex Bollbach
Nov 5 at 3:56
As I understand it, both (by default)
CADisplayLink and Timer run on the main runLoop, so any UI interaction could "stall" them - I might be over simplifying this though– MadProgrammer
Nov 5 at 3:58
As I understand it, both (by default)
CADisplayLink and Timer run on the main runLoop, so any UI interaction could "stall" them - I might be over simplifying this though– MadProgrammer
Nov 5 at 3:58
well, something relevant here is that I added a print statement in the line that pushes to the main queue and updates the UIImageView. when i start dragging, its stilled fired. So the Timer keeps firing, the processing is succeeding while I'm dragging, I just don't see the results. So the problem appears to be "downstream" of the timer firing and rendering.
– Alex Bollbach
Nov 5 at 4:00
well, something relevant here is that I added a print statement in the line that pushes to the main queue and updates the UIImageView. when i start dragging, its stilled fired. So the Timer keeps firing, the processing is succeeding while I'm dragging, I just don't see the results. So the problem appears to be "downstream" of the timer firing and rendering.
– Alex Bollbach
Nov 5 at 4:00
Possibly because the "paint" cycles are suspended? I was told in passing about
Timer running on the main run loop and how would be affected by scrolling :/– MadProgrammer
Nov 5 at 4:02
Possibly because the "paint" cycles are suspended? I was told in passing about
Timer running on the main run loop and how would be affected by scrolling :/– MadProgrammer
Nov 5 at 4:02
|
show 3 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53148062%2fany-interaction-with-the-screen-locks-animation%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Personally I'd use a
CADisplayLink, but you need to configure it so it's not affected by scrolling– MadProgrammer
Nov 5 at 3:50
sure, but i'm still running the intensive processing on a background queue and simply updating the UIImageView's image on the main queue. apple even suggests one can use both a Timer and a DisplayLink to do real time animating like this. I'll try substitution a DisplayLink but using a Timer specifically should not be the bottleneck.
– Alex Bollbach
Nov 5 at 3:56
As I understand it, both (by default)
CADisplayLinkandTimerrun on the mainrunLoop, so any UI interaction could "stall" them - I might be over simplifying this though– MadProgrammer
Nov 5 at 3:58
well, something relevant here is that I added a print statement in the line that pushes to the main queue and updates the UIImageView. when i start dragging, its stilled fired. So the Timer keeps firing, the processing is succeeding while I'm dragging, I just don't see the results. So the problem appears to be "downstream" of the timer firing and rendering.
– Alex Bollbach
Nov 5 at 4:00
Possibly because the "paint" cycles are suspended? I was told in passing about
Timerrunning on the main run loop and how would be affected by scrolling :/– MadProgrammer
Nov 5 at 4:02