Another year, another new project. Flex Mobile is well underway, and I’ve transitioned over to a group within Adobe working on gaming technologies. Of course, Adobe products, and Flash in particular, are heavily used in game development, and we’ve started to increase our focus on gaming over the past year. One of the first key technologies we’re delivering is a GPU-accelerated 3D API in the Flash Player codenamed “Molehill”, which enables incredibly beautiful and incredibly performant 3D content to be built using Flash. And just last weekend, we’ve put up our first public pre-release of Molehill as part of the Flash Player Incubator program on Adobe Labs.

Now, if you’re a hardcore 3D programmer, you’ll know exactly what to do with Molehill, and Thibault Imbert has a great introduction to the API for you. But if you’re anything like me, and your development experience has been in the world of 2D graphics or UI, you might find even this introductory material pretty head-scratching. Vertex and fragment shaders? Index buffers? Assembly language? LOLWUT?

I’ve just recently been learning more about GPU-based 3D programming myself, so I thought I’d try to make a molehill out of the 3D development mountain, and write an introduction to what this stuff is all about for those of us who are coming from the 2D world. In this first post, I’ll generally describe how modern GPUs work. I’m planning to write a follow-up post with more detail on how you actually work with the GPU for 3D graphics, and then another follow-up on how you can leverage the GPU for incredibly fast 2D graphics as well.

One caveat—I may say a few things that aren’t strictly true, mostly because I might be deliberately oversimplifying, but also because I might just be ignorant. Overall, I don’t think this picture of the world is too misleading, but please feel free to correct me in the comments.

Update: One fundamental point I meant to make when I originally wrote this post, but forgot to add, is that Molehill rendering is completely separate from display list rendering. All of the drawing that Molehill does basically ends up in a single layer that essentially draws into the background behind all of your display list content—the two don’t interact at all. I’ll discuss how you can leverage Molehill for 2D in a future post.


Digg!digg this | | 5 Comments

Adobe MAX 2010 is now just a month away, and we’re starting to prepare for a bunch of sessions where we’ll be talking about mobile development using “Hero”, the next version of the Flex SDK.

Because this is my blog, I’ll flog my own session first: I’ll be running a “Bring Your Own Laptop” (BYOL) lab on Building Mobile Flex Applications. The way these labs work is that you, er, bring your own laptop, and we give you bits to install on it for the session. Also, if you have an Android 2.2 phone, bring it (and the phone’s USB cable) along too–though that’s not required for this lab.

Glenn Ruehle and Chiedo Acholonu from the Flex Mobile team will be presenting Deep Dive into Mobile Development with the Flex SDK, which will go into detail about the mobile development features we’re adding in “Hero”, and how to optimize your development process as well as your applications when building across multiple screens.

Ryan Frishberg, another engineer on Flex Mobile, will be presenting a session on Performance Tips and Tricks for Flex and Flash Development. This session will discuss optimizing both desktop and mobile applications, and describe common performance problems that developers of every level can encounter when building Flex and Flash applications.

Evangelist Christophe Coenraets will be presenting both a session and a BYOL lab on building data-driven mobile applications with Flex “Hero” and AIR for Android. His sessions will be focused more on the data connectivity side rather than the basics of mobile application and UI development.

And from outside the building, we have RJ Owen and Juan Sanchez from EffectiveUI presenting Screens of Possibility: Pushing Multiscreen Experiences with Spark and Flex, discussing their experiences designing and developing on desktop and mobile devices. I can’t reveal details of the app they’ll be showing off in this session, but I’ve seen some early comps and I think it’s going to be very cool.

Of course, there’s going to be plenty more at MAX about mobile development, Flex, and AIR; check out the MAX Session Catalog for the complete list. Hope to see you there!

Digg!digg this | | No Comments

It’s been quite awhile since I last posted, but I’ve been keeping busy. Now that we’ve released Flash Catalyst CS5, I’ve shifted my focus to helping lead the team working on mobile application development features in Flex and Flash Builder. Last night we posted the public announcement of the next version of Flex, code-named “Hero”, which will include the first version of our mobile development features.

If you’ve been following Flex over the last year or so, you might have heard of a related effort, code-named “Slider”, which was going to be a separate version of the framework that would be specifically optimized for mobile devices. What we’ve found over the past year is that vast improvements in Flash and AIR runtime performance on mobile devices, as well as the rapidly increasing power of modern touchscreen smartphones, have made it unnecessary for us to split off a separate framework. So going forward, we’ll have a unified framework for both desktop and mobile development, and “Hero” will be the first fruit of this approach.

For a good overview of our plans for mobile development, take a look at the Flex and Mobile whitepaper, FAQ, and Adobe Labs page. We’ve also started to post draft specs for the mobile features (as well as the rest of Hero) to the Flex Open Source site, and we’ll be rolling out more over time.

I’m excited that we’ve started talking about our mobile Flex efforts publicly, and look forward to revealing more over the next few months. Watch this space!

Digg!digg this | | No Comments

The flood of Snackr downloads has finally slowed down to about 150 a day. Over 13,000 people have downloaded it so far; it looks like maybe about 500-600 people are running it daily–not bad for a little side project 🙂

Various people have requested the source code, so I’ve decided to host it on Google Code at You can file bugs/enhancement requests on the Issues tab there (the issues and wish list items from have been migrated there), and check out the source anonymously using Subversion (instructions are on the Source tab).

The source is currently in an interim state–there are a couple of half-implemented features (the ability to “star” items to read later, and the Google Reader integration that Rob is working on)–but you should be able to run what’s there (the GR stuff isn’t hooked up at all to the UI yet, and the “star” functionality works but the UI is slightly broken). I’m planning to post interim test builds there once in awhile as well.

The source also probably isn’t the prettiest code ever :), and I haven’t finished commenting it, but I’m hoping to continue cleaning it up and refactoring over time. Feel free to check it out, and let me know if you have suggestions–or, better yet, patches you’d like to submit!

Digg!digg this | | 7 Comments

Wow–nearly 600 people have downloaded Snackr in the last two days! Thanks to everyone who’s sent mail or posted comments; it’s great to know people like it. The most common requests so far seem to be:

  • Allow multiple selection in the feed list, so you can delete a bunch of feeds at once. It seems like a lot of people imported large feed lists from their existing blog readers, then realized they didn’t want to actually see all of those feeds in Snackr.
  • Support Asian language characters. Currently, Snackr uses Myriad Web, and the font is embedded in order to make fade animations work properly for text, but that font only has Latin characters. I’ll either need to add an option to use the system font (and turn off fade animations), or maybe build a version that embeds a font with Asian characters in it (though that would probably lead to a huge installer).
  • Ability to keep a list of items to read later (e.g. by starring them). I’ve been wanting this for awhile but haven’t gotten around to implementing it yet–now I have some incentive!
  • Posting the source. I do really want to do this, but I need to set aside some time to make the code slightly less embarrassing 🙂

I also noticed today as I was using it on my machine that for some short posts, the popup seems to “bobble around” a bit and end up at a very thin size (it’s different from the jittery animation on Vista/Linux; this is happening even on OS X). It’s intermittent, but it reproduces pretty regularly on certain kinds of posts. Has anybody else seen this? I’ll have to look into it–it must be a recent injection, as I never noticed it before.

I’m planning to make regular updates to Snackr, though things are pretty busy; I’m hoping I can carve out enough time to release a new version in a couple of weeks. Snackr should automatically notify you when an update is available.

Keep those cards and letters coming!

Digg!digg this | | 14 Comments

I realized a few months ago that, unlike pretty much everyone else I know, I don’t regularly use an RSS reader. Not that I haven’t tried—I used FeedDemon early on, and more recently tried out Google Reader—but never managed to form the habit of checking them regularly. Both of them are fine apps; the problem was with me. Every time I sat down and saw that I had a gazillion unread items in my hundreds of feeds, I didn’t know where to start. Eventually I just gave up trying to keep up.

Around the same time I came to this realization, Adobe AIR 1.0 was publicly released. I wanted to try to write an AIR app just for fun, and it occurred to me that I might be able to make something that would solve my RSS problem.

The result is Snackr, a ticker-like widget that lives on the bottom (or side) of your screen and scrolls random items from your RSS feeds. (It’s called “Snackr” because it lets you nibble on your feeds. Guffaw.) Here’s what it looks like on my desktop:

I’m actually finding Snackr really useful—it helps me keep up with blogs I want to keep up with, and also gives me a great smattering of items from sources I wouldn’t normally read regularly. Please try it out and let me know if you like it! (Of course, it’s still an alpha, so please expect bugs; there’s a list of known issues on the Snackr website.)

Snackr has also been really fun to write, and along the way I figured out some tips and tricks for doing various things with Flex and AIR. Some notes on that after the jump.


Digg!digg this | | 23 Comments

It’s been busy here in Thermo-land, as we work furiously (no really! we’re furious people!) to turn our vision into reality. I have a fun side project that I’m going to post about in a little bit once I get a few bugs worked out. In the meantime, here’s a video interview that Ryan Stewart, Thermo evangelist extraordinaire, did with me about designer/developer workflow in Thermo and Flex 4. It was our first video, so it’s a little blurry and off-center, but just pretend it’s artsy and edgy and you’ll be fine. (We did edit out the part where the siren went off when someone went out the wrong door in the cafeteria.)

Digg!digg this | | 2 Comments

A number of people have written me over the past few months to mention that they’ve had trouble getting the Reflection component to work in various cases. I haven’t had time to look at each of the problems, but I do have an updated version of that may work better. If you’ve been having trouble with the original Reflector code, try this one out and let me know if it fixes your problem.

Digg!digg this | | 12 Comments

Well, Thermo caused quite a buzz at MAX, and needless to say, we’re very excited about all the reaction. If you weren’t at MAX, you can see Aral Balkan’s video of the Thermo demo up on YouTube: part 1, part 2, part 3.

Since we did the demo, I’ve been semi-obsessively searching MXNA for blog posts about Thermo, and among the generally positive responses, people have also posted a number of questions and concerns. I thought I’d address some of these here, to help clarify and amplify what we showed in the demo. (Sorry–no spoilers about release dates or other features here!)

The demo showed Thermo creating a lot of bitmap graphics. Will Thermo applications be large and bitmap-heavy?

The demo happened to have a lot of bitmaps in it, since it was a CD cover browser, but Thermo will work with both vector and bitmap assets. The main difference between graphics in Thermo and in Flex today is that vector artwork in Thermo is expressed through bona-fide MXML tags, rather than opaque SWF symbols. In the demo, for example, Photoshop text layers came over as TextGraphic tags, and rectangle shape layers came over as Rect tags. Naturally, MXML graphics will also support complex Bezier paths, rounded rectangles, and so on, and will support importing from Illustrator and Fireworks as well as Photoshop.

Why is it useful to have graphics tags? Why not just import graphics as SWFs or bitmaps as in earlier versions of Flex?

For static graphics, you could argue it’s about the same. But few graphics in a Flex application are static. Much of the “rich” in RIAs comes from dynamic graphics–graphics that change in response to user gestures or dynamic data.

In Flex as it is today, developers have to create dynamic graphics by writing imperative ActionScript code. With MXML graphics, developers no longer need to recode the designer’s graphics in order to make them dynamic–they can simply modify the graphics at runtime through simple property access, data binding, the transitions/effects engine, and so on. Designers can continue to edit the graphics visually in Thermo without disturbing the developer’s code.

For example, suppose I draw a button skin in Illustrator that’s filled with a blue gradient, and we want to create multiple buttons with the same look but different colors. My developer can just import that as MXML, and then data-bind the gradient color to some style parameter. Voila–instant styleable skin, without writing a line of AS code. I can then edit the shape of the skin visually in Thermo, and the color style will continue to work, without my having to rewrite a bunch of Graphics method calls.

Now let’s say I want to animate that gradient color when I mouse over the button. Again, I can create this through declarative transitions written in MXML, rather than having to build the animation into an opaque SWF symbol. And again, because the transition is in MXML rather than ActionScript code, I can visually design that transition using the Thermo UI.

The text field that was created in the demo seemed to have its skin specified inline. Will Thermo create large single-file applications? Will the code be huge?

Thermo is being created for designers, but of course it won’t be successful unless its output can be easily consumed by developers. Thermo will definitely provide easy ways to factor the resulting code into separate files. For example, skins can be automatically put into separate output files and generalized into CSS rules. (Flex Builder 3 actually already has functionality for extracting inline styles into CSS, and we would certainly have the same functionality in Thermo.)

One example of code factoring that wasn’t obvious from the demo was that when Steven created a list from the individual CD covers, the item renderer for the list was actually created as a separate file. When he then double-clicked on an item in the list to edit it, it felt like it was being edited directly in place in the context of the larger application, but Thermo was actually making edits to the separate item renderer file behind the scenes. This is an example of how we can keep clean code separation without forcing the designer to understand the guts of Flex.

It’s great that you can turn graphics into buttons, scrollbars, etc., but what about custom components? Will Thermo work with components created by developers?

Definitely. Our intention is to make it so that developers can create components that are usable in Thermo the same way the built-in components are. Naturally, they will need to conform to certain rules and/or implement a certain API in order for those components to work well in Thermo, but our intent is to keep those requirements lightweight.

Thermo seems geared towards letting designers build a complete Flex application. Does that mean you expect designers to create business logic as well?

That’s not the goal of Thermo. One way I like to think about the designer/developer dichotomy (woo, alliteration!) was suggested by Rob Adams: developers deal with system logic, and designers deal with user logic. The two are not exactly the same, though they obviously intersect. Our goal is to make it so that designers can use Thermo to design the user logic of the application (along with importing and editing the visual design), and provide a clean way for that user logic to be hooked up to backend data and business logic by a developer.

That’s all for now. Please feel free to comment (or post in your own blogs) if you have more questions about Thermo–naturally, we can’t answer all of them at this point, but we’re really interested to hear your thoughts!

Digg!digg this | | 5 Comments

Well, here it is–almost time for MAX 2007, and the last post I made to my blog was just after MAX 2006. I’ve been a little busy 🙂 We’ve been working on some really neat stuff to show off at MAX, so stay tuned.

In the meantime, one bit of news–the Code Anatomy prototype I published in my last post is turning into a real feature! Our Learning Resources team is getting a real Flex developer to rebuild it from the ground up as a skinned, fully-reusable Flex app, and will be shipping several code samples that use it with Flex 3. Best of all, we’re planning to release the source code, so other folks can post anatomies of their own apps.

I probably won’t be coming up for air till after MAX (at least), but I will be attending, though not giving a talk. Hope to see you there!

Digg!digg this | | No Comments

Next Page »