Romain, I am sure you are, but as with the Cupcake issue from the other thread with Al, it is not transparent at all. The road map ( http://source.android.com/roadmap) doesn't contain much and doesn't seem up to date.
And don't get me started on the lack of transparency and predictability regarding *all* things Android Market. Don't get me wrong though. This is not meant in any way as a personal attack against you or in me laying the blame onto you. My point is that the communications sucks and that your, Dianne's and JBQ's life would be easier as well when someone offical from Google would put more effort into proper communications. Cheers, Mariano On Fri, Apr 3, 2009 at 10:29 AM, Romain Guy <[email protected]> wrote: > > We're aware of the shortcomings of the current garbage collector and > believe me, it's one of the things we'd really love to see improved as > soon as possible :) > > On Fri, Apr 3, 2009 at 2:04 AM, Mariano Kamp <[email protected]> > wrote: > > Anton, thanks. Very interesting. > > On Fri, Apr 3, 2009 at 2:24 AM, Anton <[email protected]> wrote: > >> > >> Check out > >> > http://android-developers.blogspot.com/2009/02/track-memory-allocations.html > >> > >> Romain Guy points out in this post that the android garbage > >> collector cannot optimize small short lived objects. These are > >> exactly the sort of objects that could be created in a physics engine > >> when it needs to generate dynamic collision constraints. A good > >> solution in this case is to use a pool of constraint objects because > >> they are all going to be the same size/object. The best solution in > >> my mind would be for the compiler to do escape analysis on the objects > >> and stack allocate them when it sees that they will never escape the > >> function. I have been told that the Java byte code can't reference an > >> object on the stack. It's possible that the Dalvik byte code can, I > >> don't know. > >> > >> I don't have a reference for this, but I assume that Dalvik's > >> inability to optimize small short lived object comes from the fact > >> that it uses a mark and sweep GC. On all of my profiling, I see the > >> GC take at least 100ms to run. For a game that means you miss from > >> three to 10 frames of animation and it makes for a pretty noticeable > >> hick up. And I don't think it's my application that is causing the > >> garbage collector to fire. Unless the OpenGL ES calls do some memory > >> allocation, which is entirely possible. I realize that any background > >> task could move to the run queue and take some time away from my > >> engine, it just happens to be the garbage collector most of the > >> time. :) > >> > >> So the result is that the Garbage collector is problematic for me > >> in two ways. First, it's not optimized to deal with the sort of small > >> objects that tend to make for good encapsulations of mathematical > >> types (like Fixed point number classes or Vector or Matrix classes). > >> And secondly it takes a long time to run when it does garbage collect, > >> resulting in dropped frames. > >> > >> -Anton > >> > >> On Apr 2, 3:32 pm, Mariano Kamp <[email protected]> wrote: > >> > It's maybe a bit off topic, but how do you know that Android's gc is > >> > rudimentary? Have you got a link handy? > >> > I only found > >> > this: > http://developer.android.com/guide/practices/design/performance.html > >> > > >> > On Thu, Apr 2, 2009 at 11:59 PM, Anton <[email protected]> > wrote: > >> > > >> > > Shaun, thanks for checking it out. Yah, I agree that the real > >> > > complexity of a physics engine comes from joints and contact > >> > > constraints. The constraints in my demo are simple minimum distance > >> > > constraints. I have a 2D rigid body physics engine that I'm > thinking > >> > > more and more about porting over to Android as well. This demo was > >> > > more of a calibration for myself to see how much computation I can > do, > >> > > and what optimizations lead to the largest improvements. I'll > >> > > probably turn it into a fun toy for the Market and then look into > >> > > rewriting my rigid body engine for Android. > >> > > >> > > Reading through Simpull I noticed that you allocate a new > Vector3f > >> > > in your Verlet update routine. I think that will be a killer on the > >> > > Android platform because of it's rudimentary garbage collector and > >> > > limited RAM. My solution was to allocate an array of fixed point > >> > > numbers, four per ball. Effectively a vector pool that didn't > require > >> > > any management because the number of balls never changed. > >> > > >> > > On Apr 2, 6:31 am, shaun <[email protected]> wrote: > >> > > > I took a look at Anton's demo on a G1 device, and I was glad to > see > >> > > > the integration of accelerometer as it really added value. I > assume > >> > > > the calculations for collision detection and response are fairly > >> > > > basic, which allows for that performance. > >> > > >> > > > Simpull will also provide good performance for a scene of that > >> > > > nature > >> > > > (all verlet, no joints). At least I believe it will. The point > >> > > > where > >> > > > simpull becomes slow is when a more complex scene is in play with > >> > > > 10s > >> > > > of objects with many joints connecting some of them. Since the > >> > > > engine > >> > > > is all verlet and no rigid body dynamics, joints are one way to > >> > > > acheive a similar result, but with a very bad performance hit due > to > >> > > > all the new temporary objects and new calculations. > >> > > >> > > > I would be super impressed to see a demo like Anton's with rigid > >> > > > body > >> > > > dynamics involved with at least some rectangles, if not other > >> > > > polygons > >> > > > and perhaps a joint or two. That is where the performance > degrades > >> > > > quickly in my experience. > >> > > >> > > > On Apr 1, 2:45 pm, mscwd01 <[email protected]> wrote: > >> > > >> > > > > Thanks Lajos for pointing APE out, I hadn't heard of it until > now. > >> > > >> > > > > Unfortunately your link to your Android port is broken, can you > >> > > > > mend > >> > > > > it as I dont fancy spending another hour porting another library > >> > > > > to > >> > > > > Android :D > >> > > >> > > > > Thanks > >> > > >> > > > > On Mar 31, 9:50 pm, lkelemen <[email protected]> wrote: > >> > > >> > > > > > Hello everyone, > >> > > >> > > > > > I was also disappointed with jbox2d's performance so I checked > >> > > > > > APE > >> > > > > > (Actionscript Physics Engine) fromhttp://www.cove.org/ape/. > >> > > > > > It was converted to java ( > http://www.cove.org/ape/java_ape.zip) > >> > > > > > so I > >> > > > > > started to convert the java version to Android. > >> > > >> > > > > > The performance is quite OK for 10-20 objects at the first > start > >> > > > > > of > >> > > > > > the app but if you exit with the back key and restart it form > >> > > > > > the > >> > > > > > installed copy > >> > > > > > (either in the emulator or on the dev phone) then it gets > slower > >> > > > > > and > >> > > > > > slower with each start. If you restart it from the emulator > (by > >> > > > > > reinstalling it) then it is faster again. > >> > > > > > Neither the pressed keys are not working (probably it is > because > >> > > > > > of > >> > > my > >> > > > > > poor Android programming knowledge). > >> > > >> > > > > > Here is a zipped Android project of it. Please experiment with > >> > > > > > it and > >> > > > > > send results to here i.e. is it slow for you also after > >> > > > > > re-re-re-.. > >> > > > > > staring?www.kotiposti.net/lkelemen/android/testape2d.zip > >> > > >> > > > > > thanks > >> > > > > > Lajos Kelemen > >> > > >> > > > > > On Mar 31, 9:26 pm, shaun <[email protected]> wrote: > >> > > >> > > > > > > I started going down the path of Object pooling. It seemed > >> > > > > > > the > >> > > only > >> > > > > > > solution when taking an existing engine and making work on a > >> > > resource > >> > > > > > > constrained system like Android on a phone. Determining the > >> > > strategy > >> > > > > > > for returning objects to the pool proved quite tough for me. > >> > > > > > > I > >> > > have > >> > > > > > > no doubt there are some experts on embedded systems > >> > > > > > > programming > >> > > with > >> > > > > > > tons of experience with object pooling. We just would be > too > >> > > > > > > lucky > >> > > if > >> > > > > > > that person(s) was also experienced with Java, physics > engines > >> > > > > > > and > >> > > had > >> > > > > > > a passion for open source and games! Is that too much to > ask? > >> > > LOL!! > >> > > >> > > > > > > On Mar 31, 12:17 pm, mscwd01 <[email protected]> wrote: > >> > > >> > > > > > > > Thanks for your feedback Shaun, I too unfortunately think > a > >> > > bespoke > >> > > > > > > > engine will need to be written for Android, which is a > real > >> > > > > > > > pity > >> > > as > >> > > > > > > > the iPhone has several physics engines which can easily > >> > > > > > > > handle > >> > > > > > > > hundreds of objects. > >> > > >> > > > > > > > Having said that Anton (2nd reply) has said he has an > engine > >> > > running, > >> > > > > > > > it would be nice to see a demo of this if that'd be > >> > > > > > > > possible? > >> > > >> > > > > > > > Clark, i'd definately host any .apk's on my own site, I > >> > > > > > > > wouldn't > >> > > put > >> > > > > > > > it on the marketplace if it wasn't a "finished" app - do > >> > > > > > > > people > >> > > > > > > > actually do that?! > >> > > >> > > > > > > > I think i'll stay away from developing games with physics > >> > > > > > > > for the > >> > > time > >> > > > > > > > being and concentrate on something else, I cant see it > being > >> > > feasible > >> > > > > > > > to include it any time soon which is a real pity. > >> > > >> > > > > > > > On Mar 31, 3:28 pm, shaun <[email protected]> wrote: > >> > > >> > > > > > > > > I am the author ofsimpull. > >> > > >> > > > > > > > > Sorry guys for the demo being out of whack forSimpullto > >> > > > > > > > > the > >> > > Core. > >> > > > > > > > > The version of PulpCore that I integratedsimpullwith did > >> > > > > > > > > not > >> > > support > >> > > > > > > > > Chrome, but you should be able to see it in IE, FF > Safari. > >> > > > > > > > > It > >> > > is nice > >> > > > > > > > > to take a look at that demo to get a feel for what the > >> > > > > > > > > engine > >> > > is > >> > > > > > > > > capable of, but the performance does not translate over > to > >> > > > > > > > > the > >> > > fixed > >> > > > > > > > > point branch/version ofsimpullwhen running on Android. > >> > > >> > > > > > > > > I ran tests on both the emulator and the actual device > and > >> > > there was a > >> > > > > > > > > significant increase in performance because of the fixed > >> > > > > > > > > point > >> > > > > > > > > implementation, but I got very frustrated that it still > >> > > > > > > > > did not > >> > > > > > > > > support the amount of objects in a scene that I > considered > >> > > > > > > > > good > >> > > for a > >> > > > > > > > > physics-based game. It seemed to handle ~10 objects > >> > > > > > > > > moving and > >> > > > > > > > > colliding OK. It has been a while since I was playing > >> > > > > > > > > with it, > >> > > so I > >> > > > > > > > > do not really remember the exact number of objects or > the > >> > > > > > > > > frame > >> > > rate. > >> > > > > > > > > I mostly remember being upset with it. > >> > > >> > > > > > > > > I am leaving the physics ideas for games out of the > >> > > > > > > > > picture > >> > > when > >> > > > > > > > > thinking Android for now. Someone would have to write a > >> > > > > > > > > ground > >> > > up > >> > > > > > > > > engine with all the performance and memory concerns of > >> > > > > > > > > Android > >> > > in > >> > > > > > > > > mind, which was not the case withSimpull.....I created > it > >> > > > > > > > > for > >> > > > > > > > > applets, then thought to port over to fixed-point for > >> > > > > > > > > Android. > >> > > It > >> > > > > > > > > works well with small scenes, but certainly not the > staple > >> > > engine to > >> > > > > > > > > use in my opinion. > >> > > >> > > > > > > > > Also, Phys2D will not run worth a damn on Android. I > >> > > > > > > > > tried it > >> > > and I > >> > > > > > > > > even went through some heavy performance tuning. > Garbage > >> > > collection > >> > > > > > > > > is the major issue even after all I did. I seriously > >> > > > > > > > > doubt > >> > > JBox2D > >> > > > > > > > > will run well either. I'll stick to what I said > earlier, > >> > > > > > > > > a > >> > > ground-up > >> > > > > > > > > solution by someone smarter than me is probably > required. > >> > > >> > > > > > > > > On Mar 31, 9:49 am, "[email protected]" > >> > > >> > > > > > > > > <[email protected]> wrote: > >> > > > > > > > > > Not tried but if you can provide us with some example > >> > > > > > > > > > source > >> > > code or > >> > > > > > > > > > put something on the market, I'm sure we could take a > >> > > > > > > > > > look. > >> > > >> > > > > > > > > > G1 performance is significantly faster than emulator, > >> > > > > > > > > > but > >> > > there are > >> > > > > > > > > > limitations. > >> > > >> > > > > > > > > > Particularly with garbage collection and memory > >> > > > > > > > > > allocation on > >> > > code > >> > > > > > > > > > that gets run continuously in loops, so I don't know > how > >> > > optimised > >> > > > > > > > > > these physics engines are for this purpose. > >> > > >> > > > > > > > > > Would be interesting to find out though. > >> > > >> > > > > > > > > > On Mar 31, 12:52 pm, mscwd01 <[email protected]> > wrote: > >> > > >> > > > > > > > > > > Oh I forgot to re-ask... > >> > > >> > > > > > > > > > > "Has anyone tested Phys2D or JBox2D on an actual > >> > > > > > > > > > > device to > >> > > see if they > >> > > > > > > > > > > run better than on the emulator? > >> > > >> > > > > > > > > > > I have a feeling the performance will better on a G1 > >> > > > > > > > > > > than > >> > > the emulator > >> > > > > > > > > > > for some reason! > >> > > >> > > > > > > > > > > On Mar 31, 12:51 pm, mscwd01 <[email protected]> > >> > > > > > > > > > > wrote: > >> > > >> > > > > > > > > > > > I did take a look atSimpull, however the demo > >> > > > > > > > > > > > application > >> > > failed to > >> > > > > > > > > > > > run as it relied on some library which wasn't > >> > > > > > > > > > > > supplied or > >> > > referenced > >> > > > > > > > > > > > to - I just got annoyed after spending two days > >> > > > > > > > > > > > failing > >> > > to get Phys2D > >> > > > > > > > > > > > and JBox2D to work in Android and didn't bother > >> > > > > > > > > > > > trying to > >> > > work out the > >> > > > > > > > > > > > problems! > >> > > >> > > > > > > > > > > > I might give it another look though... > >> > > >> > > > > > > > > > > > On Mar 30, 10:41 pm, Streets Of Boston < > >> > > [email protected]> > >> > > > > > > > > > > > wrote: > >> > > >> > > > > > > > > > > > > I wonder how well this one works on Android: > >> > > >> > > > > > > > > > > > > http://code.google.com/p/simpull/ > >> > > >> > > > > > > > > > > > > -- Anton Spaans > >> > > >> > > > > > > > > > > > > On Mar 30, 4:58 pm, Anton < > [email protected]> > >> > > wrote: > >> > > >> > > > > > > > > > > > > > I have a simple 2D physics > >> > > >> > ... > >> > > >> > read more ยป > >> > > > > > > > > > > > > > -- > Romain Guy > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time > to provide private support. All such questions should be posted on > public forums, where I and others can see and answer them > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
