I have already talked a lot about the touch slow down in this forum.
There is another observation I would like to add, may be this can help to
track the problem down.

One of my projects is an Argumented Reality Game.
Of course this kind of App eats energy (CPU cycles) like crazy:

In my app I process:
The camare, OpenGL graphics, Pseudo-3D-Sound mixing (8 simultaneous samples
+ ogg-music), 2 constant sensor imputs (acceleration, magnetic) and
additional input from trackball, hardware keys and the touch screen.

The largest slow down occurs with the touch-events.

But the next big slow down occurs with the accleration and magnetic events!
I gained up to 4 FPS on a N1 by switching from SENSOR_DELAY_FASTEST to
SENSOR_DELAY_GAME.

=> So I just wonder: May be the slow down is in no way specific to touch
events! Instead the whole input-queue-event handling is just horribly slow.
As everyonw has observed: Touching the screen will trigger (flood) lots of
events - This is similar as enabling input from other sensors - which can
slow down the app in a compareable way, too!
The main differences is only: Touching the screen will still trigger more
event than using a sesnor in *SENSOR_DELAY_FASTEST*. So the slow down
appears as less drastically...

After working a while with Android, I must say:
The design and architecture of the Java-API seems to be nice and well done
most of the time.
But the execution and implementation of the software stack as a whole seems
to be just slow, slow, slow, slow, .... All this doesn't matter if you have
lots of servers with many cores (ENTERPRISE!) but for an
embedded-soft-realtime-device I expect more!

IMHO the OS on an embedded device with a 1 GHZ CPU should not use more than
1% of the CPU to process around thousand events per seconds - and even this
i would consider slow.
Anyway, this time I resist to go into a deeper rant.

Kind Regards,
Ralf



2010/4/18 Robert Green <rbgrn....@gmail.com>

> I've tried sleep() and have switched to wait(1000), notify() / yield()
> as outlined by some other devs.  I have no empirical evidence that one
> works any better than the other.  Both consume a range between 25-36%
> of the CPU by system_process while touching.  That's a full third of
> the CPU of the device just to give me coordinates off the touch
> screen.  No one has a good workaround for this it seems and seeing the
> problem on the 2.1 emulator makes me think that Google Android devs
> have swept it aside with a casual "It's good enough."  Let's see
> replica island switch to constant-touch controls (virtual joystick or
> virtual dpad) and retain framerates over 20 with that input scheme on
> any MSM7200-based device.
>
> I'm a little frustrated.  I've spent the last 6 months writing two
> really nice games (Best work I've ever done in my 11 year programming
> career, in fact) and this is their main issue now.  They run fantastic
> on the Droid and N1, of course, and even get solid framerates on the
> MSM7200 up until you touch the screen... Then it's lag-city all the
> way home.
>
> I'm ready to put up a decent cash bounty for someone that can provide
> a reliable solution to this that doesn't involve me taking away the
> constant-touch controls.  Contact me if you have experience fixing
> this problem and are sure you can do it.
>
> On Apr 18, 5:41 am, Mario Zechner <badlogicga...@gmail.com> wrote:
> > I can confirm that the issue is still there in Android 2.0.1 on my
> > Milestone as well (and more pronounced) on my HTC Hero which still
> > runs 1.5. I put together a quick test that you can download fromhttp://
> file-pasta.com/file/0/touchflood.apk(Note<http://file-pasta.com/file/0/touchflood.apk%28Note>:
> it's 300kb because
> > i used a game dev framework to put that together which features a bit
> > more than is needed).
> >
> > Observations on 2.0.1:
> > - Touching alone decreases the performance a bit, around 2-4 frames
> > are lost
> > - Touching and moving the finger around makes things works, the frame
> > rate drops by up to 8fps
> > - The slow down is not constant but fluctuates a lot.
> > - Sleeping in onTouch does not solve the problem at all (sleep times
> > from 16 to 40ms) but only increases the lag in user input
> >
> > At least there's no garbage collection in 2.0.1 anymore due to touch
> > events.
> >
> > On 18 Apr., 11:46, Robert Green <rbgrn....@gmail.com> wrote:
> >
> >
> >
> >
> >
> > > Actually I take it back about the emulators.  I just tested again in
> > > the 2.1 emulator and realized that in my first test, I was holding the
> > > "finger" down on the screen but unlike a device, it doesn't send
> > > constant motion events if you hold the cursor still.  Moving the
> > > cursor (touch) around caused the same problem as on 1.6!  Now I'm a
> > > little worried.  Is this problem really still not fixed?
> >
> > > On Apr 18, 4:30 am, Robert Green <rbgrn....@gmail.com> wrote:
> >
> > > > Just wondering if anyone can speak on this yet.  I'd really like to
> > > > know what the state of that fix is as 2.1 is rolled out onto first
> > > > generation (MSM7200-based) devices.  As it stands, I don't see much
> of
> > > > a problem with touch eating up CPU on the Droid and N1 but those are
> > > > much faster phones so I don't think it would be quite as pronounced
> on
> > > > them.  My current 1.6 devices (G1 and Tattoo) cut my framerates in
> > > > half during any touch (with the sleep hack, even).  I optimized my
> new
> > > > games so that they would run well-enough (25-40fps) on that hardware
> > > > but they have very touch-centric interfaces so won't work well with
> > > > that bug.  I talked to a few people who run 2.0/2.1 mods on their G1s
> > > > and they said the problem isn't any better.  They still see the big
> > > > slowdown.  I tested on my 1.6 emulator vs a 2.1 emulator and there is
> > > > a huge improvement.  The 1.6 emulator slows down just like my G1 does
> > > > and the 2.1 emulator shows only a tiny bit of slowdown, which is what
> > > > I was hoping for.  That's encouraging, but I have yet to see a real
> > > > 2.1 MSM7200 update in the field so I don't know what to think yet.
> >
> > > > Anyone got anything concrete on this?
> >
> > > > Thanks!
> >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "Android Developers" group.
> > > > To post to this group, send email to
> android-developers@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> > > > For more options, visit this group athttp://
> groups.google.com/group/android-developers?hl=en
> >
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Android Developers" group.
> > > To post to this group, send email to
> android-developers@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> > > For more options, visit this group athttp://
> groups.google.com/group/android-developers?hl=en
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> > For more options, visit this group athttp://
> groups.google.com/group/android-developers?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to