Re: how to prevent TableView update on key repeat?
Re: how to prevent TableView update on key repeat?
- Subject: Re: how to prevent TableView update on key repeat?
- From: Quincey Morris <email@hidden>
- Date: Fri, 04 May 2012 00:19:47 -0700
On May 3, 2012, at 19:38 , Graham Cox wrote:
> You probably should do this as your last line:
>
> [self performSelector:<blah> withObject:nil afterDelay:[NSEvent keyRepeatInterval] + 0.1];
>
> because the key repeat rate is set by the user in the "Keyboard" system preferences and can change.
I see your logic here, but I think this isn't the optimal answer.
On the one hand, you want the delay to be as short as possible. Let's say the keyboard repeat interval is 0.83 as Marc reported. With the above delay, the user might have to wait more than 0.93 secs to see the detail view *start* to update, even after a single isolated keypress. From this point of view, the best delay is the shortest. From this point of view, the best delay is 0.
On the other hand, you want the delay to be as long as possible. We're dealing with a situation where the time to update the detail view is greater than the repeat interval. Let's say it takes 1.0 secs to do the update. Once the update (the performed method) starts to execute, then even the next keystroke is delayed for the full 1.0 secs, not just subsequent detail updates. This is a kind of freeze from the user's point of view, hence the pressure to defer it as long as possible.
[Note: The other scenario to consider here is that the user might mash an arrow key rather than hold it down. The key repeat interval seems irrelevant in this case, another reason not to use it.]
Statistically (that is, over a wide variety of key presses), the time-alignment of keypresses and updates would [I think] be randomly distributed, so the *expected* completion time after the last keypress in a series would be the total of:
-- half of the 1.0 sec freeze, or 0.5 secs, resulting from intermediate non-canceled updates occurring at "random" times
-- the performSelector delay, which must happen before the last update
-- the full 1.0 sec freeze of the last update.
That's a really long time -- 1.5 secs with no delay, or 2.33 secs with your suggested repeat-interval-based delay.
To summarize, therefore, the expected update completion time would be:
-- after a single keystroke, 'performSelector delay plus update freeze time'
-- after multiple keystrokes (whether repeated or mashed singly), 'performSelector delay plus 1.5 * update freeze time'
Since I can't control the update freeze time, I'd *really* want to set the performSelector delay to 0 -- certainly not 0.93.
My thinking about the delay of 0.1 secs (instead of 0) was do with trying to ensure that the detail update didn't start if another event was about to happen that might get delayed due to the update freeze starting first. On second thoughts, though, I think my reasoning was flawed, so I'm back to thinking a delay of 0 is the best solution.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden