So we’ve been very heads down for the past couple of months on Ti.Next. I know, I know. The suspense is killing you. It’s killing us too. I’ve tried (unsuccessfully) a couple of times to get into a place where we could open our github repo to the public so everyone could help participate and follow along in the development. However, it hasn’t happened yet.
Our approach has been to really iterate through a very wide range of R&D prototypes based on the original one that we did. We wanted to explore the vast ideas we have that solve some of the bigger problems – some even beyond the use cases of what Titanium serves today. This is our chance to really re-think Titanium, without any specific encumbrances. That means it’s a lot of mess. Our prototypes have been just that — things that we spend very little time trying to make work outside of our individual environments. And they have been very informing and very productive — but not easily transferable to others. We didn’t want to spend a whole lot of time trying to make our stuff work outside the developer’s workspace. The goal of this phase has really been to explore the opportunities and challenges. I think we’ve succeeded at this phase. We’ve learned a lot that will inform how we’re going to proceed.
Last week I took a small group of the core team working on Ti.Next on a 2-day engineering coding offsite. At this offsite we were able to make some pretty big decisions about the direction of Ti.Next and we had some pretty major breakthroughs we’re excited to share with you soon. It’s still very early days, but I can promise you that you’re going to really like what we have.
The core team
Currently, we have a number of core people working on various parts of Ti.Next. Matt Langston, Tony Lukasavage, Chris Barber, Dawson Toth, Allen Yeung and myself have been the primary team working on it — along with a few others that are advising and helping drive ideas such as Bryan Hughes, Blain Hamon, Pedro Enrique, Russ McMahon and Eric Wing (of Lanica).
Very soon. We hope to have the first part of a much larger Ti.Next project available on github as a very experimental build. It will be iOS only at first, although we are working concurrently on Android and Win8 at the same time and have good progress on those platforms too. We are focusing on the foundation compiler as our primary priority right now. From that work, we’ll build Ti.Next.
Why not Win8 and Android first?
While we haven’t been focused entirely on performance, this has been one of the major themes of our re-design. We want to remove any possibility of performance overhead in Ti.Next. We wanted to completely rethink the architecture in how we compile the code such that we can make Ti.Next as-fast, and in some cases faster, than hand written native source.
The guys over at Lanica have also been helping drive some of the performance use cases — since games are really sensitive to performance bottlenecks in applications.
One of the prototypes that we ported was a port Conway’s Game of Life to Ti.Next. This game is pretty hard on the CPU and the UI from a rendering standpoint. Tony Lukasavage originally did a port to Titanium and it doesn’t perform very well — inherently something that Ti.Current isn’t well suited for. We spent a couple of hours at our offsite to port it to Ti.Next and the results were spectacular. While we haven’t tried to do any optimizations of our Ti.Next compiler, you can see the results are pretty amazing with the video.
To explain the video, the first screen is Ti.Current (Titanium 3.1.3) running the application as the fastest frame rate we can do actually render the UI. You can see the “scanline” type rendering. Terrible.
The second video is Ti.Next slowed down as slow as possible to try and match the frame rate of Ti.Current — however, if we slowed it down to the same page, it would render so fast it would finish before you could see it.
The third video is Ti.Next running at an above normal FPS to show off the power of the Game of Life simulation. There are over 150,000+ cells being rendered on each frame render loop — and it’s blazingly fast and performs very well. On device, we get upwards to 50+ FPS. On desktop, almost 100 FPS. No optimizations, bam.
The Game of Life simulation is a good one because how tight the render loop executes and how many various small UI views are generated, not including the math routines that run on each iteration through the render loop.
Stay tuned. We will give you more updates on what’s going on very soon.