But won't it affect other Activity stuff and life cycle functions and
such?
On 10 mrt, 19:48, Stoyan Damov stoyan.da...@gmail.com wrote:
sure, it should work - I think someone has already done that
On Tue, Mar 10, 2009 at 8:26 PM, MrSnowflake mrsnowfl...@gmail.com wrote:
I have a
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
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
flyingdutc...@gmail.comwrote:
I would think so too.
As soon as
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 suhas.ga...@gmail.com wrote:
hi zombies and robots,
plz let me the solution to improve touch event
sure, it should work - I think someone has already done that
On Tue, Mar 10, 2009 at 8:26 PM, MrSnowflake mrsnowfl...@gmail.com 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'?
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 caecus...@gmail.comwrote:
Thank you both!
With those pointers, I was able to figure out and implement
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,
On Feb 19, 7:00 am, Zombies and Robots caecus...@gmail.com 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
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
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
On Jan 11, 2:25 am, Dianne Hackborn hack...@android.com 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
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
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
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
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
On Fri, Jan 9, 2009 at 11:03 PM, Dianne Hackborn hack...@android.com 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
On Fri, Jan 9, 2009 at 1:22 PM, Stoyan Damov stoyan.da...@gmail.com 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
On Sat, Jan 10, 2009 at 12:49 AM, Dianne Hackborn hack...@android.com wrote:
On Fri, Jan 9, 2009 at 1:22 PM, Stoyan Damov stoyan.da...@gmail.com 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
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 stoyan.da...@gmail.com wrote:
On
19 matches
Mail list logo
