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 at http://www.file-pasta.com/file/1/touchflood.apk, the Eclipse project with all the source can be found at http://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 > > > [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 [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 [email protected] > > > To unsubscribe from this group, send email to > > > [email protected]<android-developers%2Bunsubs > > > [email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > > -- > > ... > > Erfahren Sie mehr » -- 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
