Skip to content
January 21, 2013 / Daniel Freeman

MadComponents3D – part5: Stage3D accelerated Flex!

Image

Flex, MC3D, AS”Next”, and the new VM

Back in 2011, I pointed the way to a potential new lightweight Flex framework based on MadComponents.  In the last year, since my introduction of MC3D, I’ve been talking more about a Flex port of MC3D that enables Stage3D accelerated UIs.

Meanwhile, there has been some discussion on the Open Flex Mailing List about a future direction for Flex for the next generation language, AS”next” and the new runtime.  It seems that the next runtime will not support a traditional display list – and all graphics will be rendered via Stage3D.

There has been some discussion about graphics APIs that work a bit like the current display-list APIs, but utilise GPU accelerated Stage3D graphics.  Isn’t that what GPU-rendermode did?  Yes, but I assume AS”Next” will render vector graphics directly to Stage3D vertices, textures, and shaders.  Similar to this approach.

You’ll remember that I already played around with the idea of geometric shaders to render MadComponents.  One of the reasons that I didn’t pursue this approach is because it doesn’t solve text.  I could have combined my geometric shader with a bitmap font shader.  But the problem with bitmap fonts in Stage3D is that they’re not versatile enough.  I want to be able to freely manipulate typeface, size, and colour in the way that MadComponents allows.

Adobe recently introduced a Query Graphics API that allows you to query vector graphics on the display list.  Developers have welcomed this API as it enables them to build some interoperability between the display list APIs and Stage3D.  But again, this doesn’t solve the problem of text.

MC3D relies on interoperability between UIs drawn on the display list (allowing for elastic-resizing, and versatile styling of components/text), and rendering in Stage3D (allowing for smooth movement, and clever shader effects like reflections and motion blur).  The best of both worlds.

In MC3D, everything is still drawn on the display list, but then I capture the bitmap surfaces of my rendered UIs, and upload them to Stage3D as 128×128 texture tiles.  Unfortunately, texture upload isn’t as fast as it could be.  It’s a bottleneck, especially on mobile.  Especially with retina displays and transitions that involve multiple UI pages, or loss of Stage3D context, or redrawing the UI on orientation change.

In the future, with AS”next”, I’m hoping for one of two likely solutions to this bottleneck.  Either texture upload will get a lot faster.  Or new screen APIs will allow me to render versatile text directly in stage3D.  With full control over typeface, colour, size and styling.

MadComponents/MC3D will obviously need rewriting in AS”next” and to use new APIs, but they’re pretty straightforward lightweight classes, and it shouldn’t be too hard.

My Proposal

Personally I’m not a fan of Flex on Mobile.  MadComponents is all you need.  But I appreciate that other developers are quite attached to the Flex legacy.  It was the limitations and bloatedness of Flex on mobile that prompted me to write MadComponents in the first place.

I’ve done some quick and dirty experiments to demonstrate the feasibility of my ideas for a new Flex framework, and Stage3D accelerated capabilities.  So my proposal is that when we know more about the nature of AS”next”, the Open Flex group might get involved, and siphon-off my MadComponents/MC3D work to form the basis of a new Flex framework.

Let me make it clear what I’m willing to contribute to a new Flex component set.  It is my intention to deliver a port of MadComponents/MC3D for AS”next”.  I’m calling this project MC3D”next”.  (Some ExtendedMadness components may not make the cut.).  I invite Open Flex developers to pick up MC3D”next” and use it as the basis for a new Flex component set.

While I am willing to advise the Open Flex developers, and participate in discussions (time and other-commitments permitting), I would expect the Open Flex group to write Flex wrappers, and modifications to MC3D to allow it to work in Flex.  My efforts will be focussed developing, maintaining and porting the my existing MadComponents/MC3D work to AS”next”.

I’m open to the idea of managing MC3D”next” as an apache project.

Of course this is all speculative.  We don’t yet know enough about AS”next”.  It’s likely that a AS”next” project won’t support legacy Halo and Spark components anyway.  A new incarnation of Flex, (call it Flex”next”), will likely need to break from legacy.  But Flex devotees will likely argue that the familiar conventions of Flex are what define it – and this is what they will endeavour to preserve in Flex”next”.

MadComponents and Flex Compared

I suppose you can think of Flex and MadComponents as distant cousins.  Both use XML layouts to describe a UI.  Both adapt to screen size, pixel density, and orientation.  Both are fully-fledged and mature frameworks, with server communication capabilities, and memory management, not just UI components.  Both were designed for real Enterprise apps, not just game UIs.  Both allow for versatile styling for the appearance of component appearance and text.  For example:-

<button colour=”#FF9933″ curve=”15″ ><font size=”20″>Click</font></button>
 

Versatile styling is an important similarity.  Starling and Feathers don’t enable this.  To create a new appearance in Feathers, you’d need to create new texture skins.  Whereas with MadComponents, textures are drawn dynamically.

There are ideological differences too.  Flex components have more attributes/properties and settings that allow a lot of customisation without dipping into the code.  I’ve often referred to this as the “Swiss Army knife” approach.  MadComponents are simpler, and while they allow for some styling and customisation – beyond that, the developer is encouraged to dip into code and extend the class.  Some MadComponents are skinnable.  Simpler MadComponents omit skinning code (for brevity), and developers should subclass instead.

Stage3D accelerated Flex!

I’ve already demonstrated how easy it is to write Flex wrappers for MadComponents.  Allowing you to mix MadComponents with old Halo and Spark components.  MadComponents Flex wrappers could be written so to maintain all of the familiar conventions of Flex.

My latest experiments demonstrate how easily the new MC3D Stage3D classes can be leveraged in Flex.

Note that these are very quick and dirty experiments.  The updated FlexMadComponents project may be acquired from the Open Source code repository.

My first experiment was a simple Stage3D accelerated Flex list class.  MC3D lists are more responsive than display-list lists.  Also, I utilse a variable motion blur shader, which makes their movement seem more natural when they are scrolling fast.

MotionBlur

<mad:FlexUIList gpu=”true” dataXML=”{DATA}” percentHeight=”100″ percentWidth=”100″/>

Note the gpu attribute.  If this is true, then this Flex list is rendered using Stage3D.  I made a couple of minor tweaks to MC3D to do this – but no major rewrites.  My quick and dirty Stage3D list code is here.

A more spectacular example demonstrates MC3D page transitions in Flex.  MC3D now includes seven 3D transition modes:  Slide, Slide Over (*new), Cube, Door, Flip, Swap and Trash.

Screen shot 2013-01-21 at 00.08.52

Take a look at the mxml class here.  It uses conventional spark and halo Flex components, and ActionScript calls to MC3D’s PageTransitions class.  Notice how I hide the display list during MC3D transitions.  (FlexGlobals.topLevelApplication.visible = false;).  But the user isn’t aware of this switch.

I have to change the Flex SDK to get this example to work.  I’d merged a recent release of AIR with Flex4.6.  For some reason, my merged SDK wasn’t recognising the standard Flex components.  (“Could not resolve xxx to a component implementation” error).  I’m not sure why this happened, but when I switched to the standard Flex 4.6 SDK, everything worked fine.  Consequently, I haven’t tested this in AIR on a mobile device – but I anticipate that it will work just like it does in the browser.

Coming soon…

In subsequent instalments to this series, I’ll be describing futher MC3D effects and how to incorporate them in your own projects.

In the meantime, for community discussions about MadComponents/MC3D, come and join the facebook page:-http://www.facebook.com/groups/336764056350846/

If you’re not a member of the Facebook group – then you’re missing out on the latest discussions and innovations regarding MadComponents and MC3D.

If you’d be interested in helping to write and maintain code for MadComponents / MC3D – please let me know.  If not – please blog about this project and help to spread the word.
Also, don’t forget to leave a “star”, or “g + 1″ recommendation on the Google Code site.

About these ads

7 Comments

Leave a Comment
  1. Tink / Jan 21 2013 2:44 pm

    The Spark workflow has a great split between the functionality and the look and feel.

    Markup was used for look and feel in a skin, AS was used for functionality in the component controller class. Adobe also carried this through will classes like PopUpAnchor, and PopUpSkinnableContainer and the transitions classes were already in place.

    This meant that we could dev components not worrying about look and feel just definiing the states that the skin has to support. The markup then defines what these states look like, whether they are popups, whether they have transitions etc. Having to make an AS call to a PageTransitions class breaks this fundamental Spark concept.

    • Daniel Freeman / Jan 21 2013 2:55 pm

      It’s a quick and dirty demo. A proof of concept. I could have subclasssed ViewStack, (or written a new component) and incorporated MC3D calls into there, and hence kept transitions on the right side of the MXML/AS split for you.

      But all I wanted to do here was show that MC3D classes could be utilised by Flex. If this proposal is adopted -THEN we can get into finer details.

  2. Tink / Jan 21 2013 5:15 pm

    Fair enough, although I would expect any talk of adoption to look into the details before a decision either way was made.

    • Daniel Freeman / Jan 22 2013 2:06 am

      Difficult to get into specifics until we know more about AS”next”. This is all speculation and discussion for now.

      At the moment, the MC3D classes are kind of tagged-on. Not fully integrated with MadComponents. I envisage that with AS”next” everything can become much more integrated.

  3. Tink / Jan 22 2013 10:19 am

    “This is all speculation and discussion for now.”

    I thought my original post was opening up discussion. You’d probably find a less defensive approach would yield better results and more open discussion. I’ll now be quiet ;)

  4. Frank / Jan 25 2013 10:24 am

    I’d really love to see a productive version of your approach with Stage3D. Although Starling/Feathers is quite fun to work with (and most certainly works very nice), the emulated display list doesn’t scale very well. Put lots of display objects on the list (like it can be easily done on a tablet) and the promised 60fps will drastically drop.
    Till now, there isn’t a single AS3 mobile framework that can keep up with the requirements enterprise users have regarding tablet apps.
    Hope you and the Apache Flex guys can get something rolling in the near future, or at least agree on a concept for the next, lets just call it Flex, mobile framework that actually works.

Trackbacks

  1. MadComponents3D – part5: Stage3D accelerated Flex! « eaflash

To discuss MadComponents/MC3D, join the Facebook group!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 86 other followers

%d bloggers like this: