Question - onTouchEvent very slow

[pgp44]

Hello

I am trying to convert the tutorial http://developer.android.com/guide/topics/graphics/opengl.html to Clojure using the fork I found on this site (also using the main 1.4 release but with the same result)

The issue is that the onTouchEvent is behaving very slow.

Logcat says

05-06 11:03:30.680: INFO/InputDispatcher(170): Application is not responding: Window{4143d7f0 com.example/com.example.Activity paused=false}. 9270.0ms since event, 5001.9ms since wait started 05-06 11:03:30.680: INFO/WindowManager(170): Input event dispatching timed out sending to com.example/com.example.Activity

Might be related to how Clojure generates separate java class per overridden/implemented method, but I have no real clue

Any tips would be warmly welcomed as currently, my planned pet project to play around with opengl on android using Clojure seems pretty unworkable

Many thanks

Peter

[sattvik]

Is your code available somewhere? It'd be a lot easier for me to help if I had a copy of what you are trying to run.

[pgp44]

I uploaded it to github. It's not much, and all is new to me, so I am sure it's a bit...ugly and not clojure ideomatic at all, but I don't think that should matter in this case.

I hope you can access it from https://github.com/pgp44/Androjure/tree/master/src/com/example

Many thanks

Peter

[pgp44]

Fwiw, a bit more info.

I added a few log statements, both to the clojure and the java version of the app.

Based on the logcat output, the java app processes the onTouch in <=10ms max (most of the time start and stop time are the same), the clojure app requires typically more than 200ms

Peter

[sattvik]

Hello, Peter,

I was able to spend only a little bit of time looking into this yesterday. I wasn't able to reproduce your specific problem, but I did see the GC kicking in quite often.

What are you using as your test platform?

[pgp44]

Thanks for your reply. I am testing on a Motorola Xoom (first version with 32Gb) with Android 4.0.4

Is there anything else I can measure/profile/test to try and get to the core of the problem? The app as such seems a pretty straightforward port of the Java version, but I am not very proficient in clojure so I might be doing stupid things.

Tx

Peter Peter

[pgp44]

I tried to understand the information provided by DDMS and Traceview

Seems that the majority of the time when dealing with "touch moving" over the screen is spent in clojure.lang.Reflector related calls which are invoked in the GLRenderer.onDrawFrame function

Of 100%, 65% is spent in onDrawFrame most of which is divided between clojure.lang.Reflector.invokeStaticMethod (52%) and clojure.lang.Reflector.invokeNoArgumentInstanceMember(46%)

In both these cases only a very small fraction (1% and 0%) is spent in the invokeMatchingMethod (which I assume calls out to the android code). The rest is spent in e.g. libcore/util/CollectionUtils.removeDuplicates, java.lang.class.getPublicMethodRecursive

Not 100% sure this is all correct nor whether it helps getting closer to a solution, but it could explain the difference between a pretty equivalent Java and Clojure app.

Btw - I am not using Eclipse to build but IntelliJ, and it is a bit of a hassle to get the order of clojure and generated java resources correct. Seems unlikely, but perhaps I messed up there?

Again, all suggestions to try and get this under control, more than welcome!

Tx

Peter

[pgp44]

After adding typehints it seems to be a bit better. Next experiment will be to do the reflection in clojure on initialization.

Seems to become pretty unworkable, assuming that will proof the only way to get this "performing normally"

Peter

[sattvik]

I apologise I have not had time to look into this issue, but yes, adding type hints can make a huge difference performance-wise. The easiest way to see if reflection is an issue, you can always ensure that *warn-on-reflection* is set during compilation and fixing any warnings that come up. More information is available at http://clojure.org/java_interop#Java%20Interop-Type%20Hints

[pgp44]

For the record...I guess :)

After hacking out reflection warnings by adding type hints the app now behaves more or less acceptable. It is however still observably slower than the java version.

Trace shows that a substantial amount of time is spent in clojure.lang.KeywordLookupSite called from GLRenderer.onDrawFrame.

That is the only one in the top 20 (or so region) that looks suspect at first sight.

Updated code on https://github.com/pgp44/Androjure/tree/master/src/com/example but to be honest. It was already pretty ugly, after the hacking away of the type warnings it really is bad. Plan is to refactor it, once the trace looks more or less acceptable...meaning the bulk of the time spent in android rendering methods

In case anyone would have indications as to what might cause this and/or how it can be avoided...that would be appreciated indeed!

Tx

Peter