The fundamental issue is that there are too many instructions per
event being executed. There is no way around it other than optimizing
the event handling code in KeyInputQueue. No amount of waiting or
sleeping will fix that because those events must run through that code
and that code appears to be very slow. It surprises me because it's
truly performance critical code and this issue has been known since
1.1/1.5 and it still doesn't appear to be fixed in master. I'm
looking at it now and the author(s) didn't even follow Android's best
optimization practices. Simple things like declaring virtuals with
local variables aren't done.
For a moment today I was considering taking the input stack (EventHub,
KeyInputQueue and InputDevice) and hacking it into my own input stack
which reads off the event devices much more efficiently but I can't
find any way to stop the system stack from running and consuming CPU,
so that hack is out (and probably good because I really didn't want to
go there - waste of time and probably wouldn't work right anyway).
In my activity:
public boolean onTouchEvent(MotionEvent e) {
return false;
}
And system_server still consumes about 36% of the CPU while moving my
finger around. That proves there is nothing a developer can do to
work around this. I think I'll take this issue to the platform group
now and try to file more specific bugs.
On Apr 18, 10:38 am, Ralf Schneider <li...@gestaltgeber.com> wrote:
> 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%2Bunsubs
> > > > > cr...@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%2Bunsubs
> > > > cr...@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%2Bunsubs
> > > cr...@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%2Bunsubs
> > cr...@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
> 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
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
