Android Graphics, Animations and Tips & Tricks

Chet Haase and I recently gave several presentations at Devoxx and the San Francisco Android user group. We’ve just posted the slides for two of these presentations:

These two presentations will teach you about development techniques we use every day on the Android team. The second one in particular shows what tools we use to track down performance issues. The videos of these two presentations are available on Parleys for registered users and will be available for free later next year.

43 Responses to “Android Graphics, Animations and Tips & Tricks”

  1. Josh says:

    Early on in the first set of slides, there’s a shot of a SurfaceView with the Galaxy live wallpaper positioned over a few others, like Grass. The arrangement looks more like that of the standard wallpaper picker, though, not the live wallpaper picker. For instance, I see a static list of live wallpapers in my picker (Incredible/Froyo), and when I pick one I go to the Preview screen. Is that a real screen shot (of what?), only available on some devices? Or is it just fabricated to show what a SurfaceView might be?

  2. Romain Guy says:

    Josh, it’s a made up example.

  3. Kristoffer says:

    I see that you dont render graphics by hardware i Gingerbread either… When are we going to see smooth GUI:s?

  4. Romain Guy says:

    It is very naive to think that using the GPU to render text and bitmaps is suddenly going to fix every issue you may see. There are *many* things that can be done to improve performance of the UI without using the GPU. Notably improving touch events dispatching, reducing garbage collection pauses, asynchronous operations to avoid blocking the UI thread, etc. A one year old NexusOne (and other devices before) is perfectly capable of scrolling a list at close to 60fps (limited by the display’s refresh rate.) Using GPUs to do 2D rendering can introduce other types of inefficiencies (fillrate can be an issue, some primitives like arbitrary shapes are complicated to render with antialiasing, textures need to be uploaded, shaders compiled, etc.) I am not saying we won’t do GPU rendering for the UI (I have worked on it myself a couple of times to test it) but please stop assuming that this is what has to be done *right now*.

  5. Kristoffer says:

    Thanks for being honest about the GPU-rendering. No modern Android phone is capable of the same smooth framelocked rendering as *put certain flamebait here* though. I am a big fan of the big Android, dont take me wrong, it would just be nice to see Android being capable of a completely stutterfree default GUI, soon.

  6. JayBomb says:

    I appreciate your thoughtful response to some of Kristoffer’s question. Perhaps it is naive to believe that GPU acceleration is some kind of magic bullet. However, the most interesting part of his question seems to be unaddressed. “When are we going to see smooth GUI’s?”

    To many of us laymen, it is difficult to understand why our 1GHz Nexus’s, Droid’s and Incredible’s (“Superphones” right?) lag so obviously compared WP7 or even the original iPhone. Personally, this is my single biggest complaint with Android, and I would love to know that the sluggish UI issues are being seriously addressed. Furthermore, are we wrong to expect such improvements in Gingerbread?

  7. Kristoffer says:

    @Jay
    Time will tell I guess…

    My thougts on the CPU-offloading part is that despite less good touch events dispatching, garbage collection pauses, e.tc. you still have recources for rendering intact. It is as much about hardware acceleration an it is offloading the CPU. My bet is that when dualcore CPUs enter the market in the beginning of next year, this won’t be a problem anymore. Then Google will have waited out the problem by adding beefier hardware every year for three years until they had enough horsepower to throw at the “Pixel Flinger”.

  8. Kleptine says:

    Arg. If I understand correctly, loading all of these bitmaps as 8888 will substantially increase the amount of memory used by each image.

    The problem is that my application stretches the limits of the VM limit (usually only 24mb) to the extreme. Specifically for the main rendering Surface, ARGB_8888 is far to much detail than I actually need. I really beg you not to depreciate ARGB_4444 and others, at least until increasing the VM-heap to at least around 32mb.

    If I’m wrong about the changes, though, please tell me, as it would really ease my concerns that my application won’t be able to run under Gingerbread.

  9. Romain Guy says:

    We of course increased the amount of RAM available to each application.

  10. Kleptine says:

    @Jay/Kristoffer

    It seems to me that one of the more blatant scrolling inefficiencies is the fact that it take a couple hundred milliseconds to detect the scroll action after pressing the ListView. It’s fairly apparent on my Nexus One.

  11. Kleptine says:

    @Romain Guy
    Ah, glad to hear it!

  12. Dianne says:

    @Kleptine That isn’t any kind of inefficiency, the delay is deliberate to avoid the worse situation of a single tap causing the list to move a bit. That is, if it started tracking the finger immediately, the slight unavoidable movement of your finger when you tap would be seen as the entire list moving during that tap.

  13. Kleptine says:

    @Dianne:
    I definitely realize that, however it seems far too large of a buffer zone. You’ll notice an iPod touch has this zone pretty much set to zero; things scroll as soon as you move your finger.

    What I suppose I was really suggesting was to do a quick bit of testing to see how much play the average finger actually has when pressing an item (which really doesn’t seem like it will be much if no one is having problems on an iPhone), and adjust the parameters accordingly.

  14. Romain Guy says:

    @Kleptine: this was of course tested with users, and the threshold value was chosen based on the “noise” introduced by simply touching the screen.

  15. sergk says:

    Any news about RenderScript API? Will it still private in GB?

  16. Romain Guy says:

    RenderScript will still be private in Gingerbread. We’re still making (big) changes to it.

  17. Kleptine says:

    @Romain Guy
    Ah, that makes sense. If it’s a problem with the screen itself, I guess there’s not much that can be done. Thanks for the quick answers.

  18. JayBomb says:

    I’ve read several of your comments and responses to pleas for GPU acceleration in Android on various sites, here of course, Twitter and even issue 6914 on code.google.com. You are always quite adamant that GPU acceleration is unnecessary saying, “many things can be done”, “garbage collection”, blah blah blah. Well, I’ve been watching reviews and demos of the Nexus S, and guess what? Scrolling in the browser still sucks. (Forgive the bluntness.) The optimizations and “garbage collection” that has been advertised and touted, clearly aren’t enough. Not the in the browser anyway, and especially not when Flash is enabled.

    During development, how do you guys open a webpage, scroll around and say “yeah, that’s good enough”? Every other manufacturer appears to address this issue with GPU acceleration. Perhaps it’s time to stop making excuses and do it too. And yes, “*right now*”.

  19. Romain Guy says:

    @JayBomb I did not say it is unnecessary. What I said is that it’s wrong to believe it is *the* solution. If it was, we would have done it already.

  20. JayBomb says:

    http://www.youtube.com/watch?v=MkZZXeF5uV8

    This is a video of a Galaxy S with GPU accelerated browser. Whatever they’ve done, seems to be *the* solution.

  21. Panos says:

    @JayBomb

    Wow! The scrolling and zooming on that GPU accelerated browser looks pretty awesome! Thanks for posting the link to the video! Love my N1, but hope the Google guys take notice!

  22. azureus says:

    Romain,

    Thanks for your replies on the issue. Could you just give a reason and brief explanation on your reasoning behind holding back on GPU acceleration? Because there are a lot of intelligent and knowledgable people out there who think it’s a good idea, and a lot of rival phones which use the GPU in the browser and UI very well.

    Just explain what the thinking is here and we’ll most likely all relax a bit. It’s just at the end of the day what Jay has said reflects what the average person thinks – how could you think the current browser performance is good enough? Just fill us all in and maybe we’ll understand!

    (btw i have the nexus s and it’s a brilliant phone – well done on it overall – apart from browser scrolling ;)

  23. JayBomb says:

    I saw your name on Mike Cleron’s CES demo and to show that I’m not only a nay-sayer, I wanted to say that Honeycomb looks pretty fantastic (scrolling too!). It gets me excited for Android again.

  24. Romain Guy says:

    @azureus We don’t deny that the GPU can be very useful, but based on our observations, there were other things we had to fix that were more helpful at the time (for instance reducing garbage collection pauses.) The browser is a different story because it does not use the same rendering pipeline as other UI widgets. Because it runs native code, it is not affected by the same issues as standard apps. I however do not work on the browser and I won’t comment further on it.

  25. EagleNobunaga says:

    Romain,

    I totally agree with your view, there are really a lot of stuff have to be fixed before the GPU come in handy, i am currently working in a tech company making Android tablet( yes, one of many ), i am in charge of framework and memory management( especially bitmap management, our software rely really hard on bitmaps, my current solution is reuse every bitmaps possible ), and yes, i owned many android phones, cheap one as G1 to medium one like milestone and high end one like Galaxy S, and i do wish someday i can see a flawless UI from Android, of course it is also part of job to make it happen, i can’t say much about our stuff but what i can say is i am proud of our framework ( i rewrote part of viewgroup especially listView, gridView, *Galley* ), yes, we don’t have GPU power, still, by carefully programming each small part, our framework is smooth like hell. i read and learned a lot from all your post or presentation, you should take part of those credit, i hope my company can receive honeycomb ( i have no idea when we can get it, lol) soon and we can make Android better and stronger.

  26. hava perdesi says:

    has been described has been impressive in terms of visual and descriptive about the site is always so difficult to find explanatory to people I know now I would recommend you all congratulations

  27. hava perdesi says:

    quite impressive really liked your writing an article full of realistic expressions have been presented in detail to compile a very nice thank you..

  28. Never seen it for that perspective but i can see it working.