The ANR dialog is shown when you aren't responsive for 5 seconds. We should
be talking about waiting for ~20ms only for motion events. These are in
completely different realms.
On Wed, Mar 11, 2009 at 7:22 AM, Streets Of Boston
wrote:
>
> I would think so too.
>
> As soon as you execute wait st
I would think so too.
As soon as you execute wait statements in your main message-
dispatching thread (e.g. sleeps, waits, waiting for I/O, long lasting
loops, joins, etc.), you run the risk of the application getting
unresponsive. Android may pop up a message telling the user that the
applicatio
But won't it affect other Activity stuff and life cycle functions and
such?
On 10 mrt, 19:48, Stoyan Damov wrote:
> sure, it should work - I think someone has already done that
>
>
>
> On Tue, Mar 10, 2009 at 8:26 PM, MrSnowflake wrote:
>
> > I have a question about this: While sleeping the ui
sure, it should work - I think someone has already done that
On Tue, Mar 10, 2009 at 8:26 PM, MrSnowflake wrote:
>
> I have a question about this: While sleeping the ui thread works,
> would it also work to wait() the main thread and notify() it when the
> new frame 'starts'?
>
> On 20 feb, 10:4
I have a question about this: While sleeping the ui thread works,
would it also work to wait() the main thread and notify() it when the
new frame 'starts'?
On 20 feb, 10:41, suhas gavas wrote:
> hi zombies and robots,
> plz let me the solution to improve touch event performance
> I have got stuc
hi zombies and robots,
plz let me the solution to improve touch event performance
I have got stuck because of the sam
regards,
suhas
On Fri, Feb 20, 2009 at 12:46 PM, Zombies and Robots wrote:
>
> Thank you both!
>
> With those pointers, I was able to figure out and implement working
> versions
Thank you both!
With those pointers, I was able to figure out and implement working
versions of both techniques. Now I just have to decide which one I
like better and finish writing my game...
--~--~-~--~~~---~--~~
You received this message because you are subscri
On Feb 19, 7:00 am, Zombies and Robots wrote:
> I've been trying to follow everything you guys have been talking
> about, but I must admit that after trying several ways of implementing
> what you suggest, I still haven't been able to achieve any positive
> results. Could one of you provide some
Here's a hint - override public boolean dispatchTouchEvent(MotionEvent
ev) instead of onTouchEvent - this *does* save quite a few cycles.
You sleep using whatever you find more appropriate - Thread.sleep for
interruptible sleep or SystemClock.sleep for non-interruptible one.
HTH,
Stoyan
On Thu,
I am also developing games which may make heavy use of onTouchEvent(),
so this thread looks very helpful to me as well.
I've been trying to follow everything you guys have been talking
about, but I must admit that after trying several ways of implementing
what you suggest, I still haven't been ab
On Jan 11, 2:25 am, "Dianne Hackborn" wrote:
> Fwiw, you should generally avoid trying to directly control scheduling. Let
> the kernel schedule the threads as needed; the only issue you had here was
> that your main thread was using as much CPU as it could get, since it was
> continually proces
Thanks, glad to hear it helped. Sorry I was slow responding to your last
detailed message.
Fwiw, you should generally avoid trying to directly control scheduling. Let
the kernel schedule the threads as needed; the only issue you had here was
that your main thread was using as much CPU as it coul
Dianne, I want to thank you again for your advice - it actually
helped. I process at most 10 touch movement events per second (good
enough for the app) and sleep the UI thread after the moves - this did
boost the second thread enough so that most of the app's time is spent
in physics updates and d
I'll add that the time consumed by my view's onFingerMove is 2/3 of
the time to call (MotionEvent.getAction + .getX() + .getY()) - that
is, I'm pretty sure I'm not doing anything funny in my touch event's
handler.
On Sat, Jan 10, 2009 at 3:14 AM, Stoyan Damov wrote:
> On Sat, Jan 10, 2009 at 12:
On Sat, Jan 10, 2009 at 12:49 AM, Dianne Hackborn wrote:
> On Fri, Jan 9, 2009 at 1:22 PM, Stoyan Damov wrote:
>>
>> I do "yield" to the main thread by calling mainActivity.runOnUiThread
>> w/ a no-op (cached) runnable once per second but I guess that's not
>> enough. I'll try increasing that to
On Fri, Jan 9, 2009 at 1:22 PM, Stoyan Damov wrote:
> I do "yield" to the main thread by calling mainActivity.runOnUiThread
> w/ a no-op (cached) runnable once per second but I guess that's not
> enough. I'll try increasing that to see if it will make a difference.
> I'd rather run the game @ 40
On Fri, Jan 9, 2009 at 11:03 PM, Dianne Hackborn wrote:
> The system delivers events as fast as you will process them. This is a
> common issue when a game is designed where most of the work is done outside
> of the main thread
This makes sense to me.
> probably the best solution at this point
The system delivers events as fast as you will process them. This is a
common issue when a game is designed where most of the work is done outside
of the main thread -- probably the best solution at this point to to sleep
for some number of milliseconds each time you process an event to throttle
t
OK, I measured how many moves per sec the view gets when I hold my
finger as still as possible.
The result is surprising (I expected more and was hoping that's the
reason for the slow down) and is about 70 moves/second.
I still don't get why the view gets 70 moves/sec if I'm not moving my
finger a
19 matches
Mail list logo
