Excellent work, Mario. I think it's quite clear that the input processing code in Android needs help. Eating 20-30% of a Cortex A8 is a pretty big deal.
On Apr 18, 4:21 pm, Mario Zechner <[email protected]> wrote: > For fun i extended the example i posted earlier. It now feature cpu > usage output derrived from /proc/stat which should be enough to given > an indication of the slow down occuring due to touch events. > > The setup: > > - A GLSurfaceView > - An OnTouchListener that does nothing but return true > - A simple renderer thread which is throttled via a Thread.sleep(200) > to 5 frames per second which outputs the frames per second as well as > the cpu usage > > Observation on Milestone with 2.0.1: > - load without touching the screen - 4%-12% > - load with touching the screen - 24%-44% > > due to the way i measure the cpu usage it of course fluctuates quiet a > bit, the overall tendency can be easily derrived though. > > You can find the apk athttp://www.file-pasta.com/file/1/touchflood.apk, > the Eclipse project with all the source can be found > athttp://www.file-pasta.com/file/0/touchflood.zip. > > On 18 Apr., 22:18, Robert Green <[email protected]> wrote: > > > > > 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 <[email protected]> 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 <[email protected]> > > > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > > [email protected] > > > > > > > To unsubscribe from this group, send email to > > > > > > > [email protected]<android-developers%2Bunsubs > > > > > > > [email protected]> > > > > > > > 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 > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
