And then the check box up at the top, that’s one of the animated PNG animations that we have for the AnimatedStateListDrawable. And render thread. So this is kind of an implementation detail, but it’s a really interesting one, so I’m going to talk about it anyway. And it’s also important, and probably increasingly important as we go forward, for performance.
One of the issues that we have with UI and graphics animations, and performance in UIs in general and Android, is that everything needs to stay on the UI toolkit thread, which means if you’re doing something silly like querying a web service on your UI thread, A, don’t, and B, you’re going to freeze your UI. And C, see A before. Don’t do that. But you can get yourself into these positions, in some cases necessarily, because that is an operation we need to perform in the UI toolkit thread, and therefore everything else happening halts.
A really great example of that is when you launch an activity, then we need to inflate that new activity if you’re in the same process on the UI toolkit thread.
Well, in the meantime, if you’re running an animation that also needs to run in the UI toolkit thread, then that animation is going to stop while the activity launches. So we came along with the render thread technology to be able to break apart the two processes of rendering. There’s the creating the display list of what we actually want to render, and then there’s actually executing that display list and telling the GPU how to draw this stuff. And we broke these two apart.
So we create it on the UI toolkit thread, where it necessarily has to be, and then we pass that information over the wall to the render thread to let it actually execute and talk to the GPU on a separate thread. In particular, what we want to do is take these atomic animations and send them over so they can perform completely autonomously on the render thread so that now you’re not beholden to the state of the UI toolkit thread if you are inflating an activity or doing an expensive operation, because the animations can happen asynchronously at the same time.
So we’ve started down that path right now. There’s going to be more work going forward on that. A great visual example of that right now is the touch feedback ripples, which happen on the render thread, and they happen completely autonomous of the UI toolkit thread, which is why when you click on something that launches a new activity, the ripple continues to actually animate while the new activity window is coming up.
There’s some important I/O talks where we go into a lot more gory detail in a lot of this stuff, so I would suggest that you check those out. Some of them are, of course, the material design talks themselves. They’re scattered throughout the conference, and I frankly didn’t look up the names and titles, so they’re not on this slide.
There are two sessions in particular that go into the more techie details. One is called Material Science – this is tomorrow morning at 11:00 — and the other is Material Witness. Material Science is an overview of sort of the entire space, kind of a deeper dive of everything I’ve just talked about. And Material Witness is a use case where Romain and I wrote particular apps using these APIs and then talk about how they were actually implemented and how the technology works. The sessions in your schedule right now probably have different names because we were withholding the material name until after the keynote, but the real names will be out there very soon. So check those out, and there’s also an I/O Byte on activity transitions in particular that you can check out as well.
In Support Lib, there’s the RecyclerView and the CardView stuff that I talked about. There’s also other capabilities, including palette capabilities for doing color sampling stuff. This was mentioned in the keynote. Matias was talking about that this morning. There’s RoundedBitmapDrawable. This comes into play in things like CardView. It’s very useful. ViewPropertyAnimator. This was done as more of an implementation detail of getting RecyclerView animations to work. And NotificationCompat is useful for Android Wear stuff.
And we’re onto WebView, where we have updated to Chromium, build M36, which enables various useful web standards, so you now have WebGL, and the other things listed on the slide. Check out the I/O Byte “What’s New In WebView” for more detailed information.
On the graphic side, there is an update to OpenGL ES 3.1 with new compute shaders and new shader language capabilities. We have bindings in the SDK as well as NDK, and obviously it’s backward compatible with OpenGL ES 2 and 3, as they usually are. And you can say use feature in your manifest to specify this version exactly.
The other important thing to mention was also mentioned by Dave Burke in the keynote. It’s the Android extension pack. We basically collected a bunch of extensions that are really useful and powerful together and sort of bring the platform up to the current state of, say, console gaming hardware. And all of these come as a bundle, and we’re working with partners to enable one and all of these extensions together. And there will probably be a mechanism in the future for you to ask for this particular capability, which basically gives you the whole sandbox of capabilities altogether. Lots of useful stuff in there, including tessellation, enhanced geometry shaders, and texture compression would be nice. Camera and audio space.