Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-settings.php on line 512

Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-settings.php on line 527

Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-settings.php on line 534

Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-settings.php on line 570

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/twinsen/today/wp-includes/classes.php on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /home/twinsen/today/wp-includes/wp-db.php on line 306

Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-includes/cache.php on line 103

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/twinsen/today/wp-includes/cache.php on line 431

Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-includes/query.php on line 61

Deprecated: Assigning the return value of new by reference is deprecated in /home/twinsen/today/wp-includes/theme.php on line 1109

Strict Standards: Declaration of Walker_Comment::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/twinsen/today/wp-includes/comment-template.php on line 1266

Strict Standards: Declaration of Walker_Comment::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/twinsen/today/wp-includes/comment-template.php on line 1266

Strict Standards: Declaration of Walker_Comment::start_el() should be compatible with Walker::start_el(&$output) in /home/twinsen/today/wp-includes/comment-template.php on line 1266

Strict Standards: Declaration of Walker_Comment::end_el() should be compatible with Walker::end_el(&$output) in /home/twinsen/today/wp-includes/comment-template.php on line 1266

Strict Standards: Redefining already defined constructor for class WP_Dependencies in /home/twinsen/today/wp-includes/class.wp-dependencies.php on line 31

Strict Standards: Redefining already defined constructor for class WP_Http in /home/twinsen/today/wp-includes/http.php on line 61
Just Suppose

Jan 11 2010

Get Fancy with Flex 4 - Part Two

Published by Corey under Flex 4, Uncategorized

As a quick follow-up to my last post, here is another nifty transition. It’s a radial version of the classic “Squish” transition, in that the old image starts to peel away from the center out, to reveal a new image.

Here’s a simple example where I exaggerate the effect a bit to show you how it works - a possible prototype for a dynamic color picker (or something, yeah I’m grasping):





I wanted to go a bit further and mention that you can use any of these transitions within your AIR applications as well, makes for very fun desktop toy..or at least for fun transitions between states of a fun desktop toy, whether it be a cross fade, twist, morph, radial wipe… just experiment!


 

Click here to install the ‘flowers’ applet for desktop use.

Click here for the sample and shader source code.

One response so far

Jan 06 2010

Getting Fancy with Flex 4

Published by Corey under Flex 4

For those familiar with the Pixel Bender feature that shipped with Flash 10 you know that it’s possible to author custom image filters or blend filters for static content. With Flex 4 and the new AnimateTransitionShader effect you can now leverage Pixel Bender filters as the “engine” behind animated custom state transitions.

The idea behind AnimateTransitionShader is that the SDK will take care of the gory details behind:

  1. Taking a before bitmap snapshot of the effect target before the state change.
  2. Taking an after snapshot of the effect target in the new state.
  3. Assigning the before and after images to the Pixel Bender shader and animating the ‘progress’ property of the shader, updating the screen accordingly with the results of the shader operation for each frame.

Let’s take a quick look at a simple example.

Consider the animation below where our applet has a label or caption that changes values every few seconds. In this example we transition “to” each state using a modified version of the Hexagonal Tiling shader written by Petri Leskinen.





A quick walk-through of the code below for inquiring minds:

  • A standard Flex 4 applet consisting of two states.
  • A label is declared whose text value has one of two values depending on the current state (”Before” or “After”).
  • The magic: We declare an instance of an AnimateTransitionShader effect to serve as the default transition effect. It’s worth noting that we target the parent of the label in this case (”ticker”) because we want the bounds of our ‘before’ and ‘after’ images in our raster transition to be identical - this is a requirement of the AnimateTransitionShader effect. The effect is also initialized with a reference to the ‘HexCells’ Pixel Bender kernel.
  • A timer changes the current state every 2.5s.

That’s really all there is to it. When the state change occurs the effect will grab the input images and feed them to the HexCells shader and then animate the ‘progress‘ attribute of the shader from 0 to 1 as the transition progresses. The result of each animation frame is rendered to the screen by the Flex SDK.

I won’t go into details here about the exact interface we require for the Pixel Bender shader, but I encourage you to examine the example source included as part of this post.

For what it’s worth, the Spark CrossFade and Wipe effects that ship as part of Flex 4 are further examples of Pixel Bender shaders that can be used for simple transitions.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark"
        xmlns:mx="library://ns.adobe.com/flex/mx" width="300" height="150"
        applicationComplete="onAppComplete()" backgroundColor="#000000" >
   
    <fx:Script>
        <![CDATA[
            private var timer:Timer;
            private function onAppComplete():void
            {
                timer = new Timer(2500);
                timer.addEventListener("timer", onTick);
                timer.start();
            }
           
            private function onTick(e:Event):void
            {
                currentState=currentState=='State1'?'State2':'State1';
            }
        ]]>
    </fx:Script>
   
    <s:states>
        <s:State name="State1"/>
        <s:State name="State2"/>
    </s:states>
   
    <s:transitions>
        <s:Transition>
            <s:AnimateTransitionShader target="{ticker}" duration="1100"
                shaderByteCode="@Embed(source='HexCells.pbj',
                mimeType='application/octet-stream')"
/>
        </s:Transition>
    </s:transitions>
   
    <fx:Style>
        @font-face {
            src: url("MyriadWebPro-Bold.ttf");
            fontFamily: "Myriad";
            embedAsCFF: true;
        }
    </fx:Style>

    <s:Group id="ticker" width="300" height="150">
        <s:Label fontFamily="Myriad" text.State1="Before" text.State2="After"
             color="#FFFFFF" textAlign="center" buttonMode="true"  verticalCenter="0"
             fontSize="44" width="100%"/>
    </s:Group>

</s:Application>

The sky is pretty much the limit here. In fact since the effect is just a standard Flex Effect you can also specify interpolation options. Another example (below) uses a simple “twist” shader that you can use to essentially flip between two states of an effect target. In this case I’ve added a custom Bounce easer to the transition.



The source for the twist example follows, the bulk of the sample is identical to the one prior, so I’ve excluded the common code (full source of the examples is included in the archive attached to this post below).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
...
   <s:transitions>
        <s:Transition>
            <s:AnimateTransitionShader target="{ticker}" duration="1200"
               shaderByteCode="@Embed(source='Twist.pbj',
               mimeType='application/octet-stream')"
>
                <s:easer>
                    <local:MyBounce/>
                </s:easer>
            </s:AnimateTransitionShader>
        </s:Transition>
    </s:transitions>
   
    <s:Group id="ticker" width="100%" height="100%" >
       <!-- Solid fill for our effect target so captured bitmap contains
                bounds of our Group -->
       <s:Rect width="100%" height="100%">
            <s:fill>
                <s:SolidColor color="#FFFFFF"/>
            </s:fill>
        </s:Rect>
        <s:BitmapImage source="@Embed(source='CalcLarge.png')"
            source.State2="@Embed(source='CalcSmall.png')"
            verticalCenter="0" horizontalCenter="0"/>
    </s:Group>
    ...


Download the cookbook code for each of the samples here.

For more information about blend shaders check out this article by the Flex effects guru himself, Chet Haase: Shader Transitions in Flex 4.

And to browse the sources of several Pixel Bender shaders (which you’ll have to port for use as blend shaders) - check out the Pixel Bender Exchange.

12 responses so far

Mar 26 2009

Exploded Schematic View of Flash and Flex Apps

Published by Corey under Technology, Toys

I am not sure who wrote FlexSpy back in the day but it struck me that such a tool could benefit from an interactive schematic view of the display list it’s introspecting. If anything it’s useful to see sometimes just how a component or UI is composed.

 

Included along with this post is a sketch (proof of concept) I put together over coffee this morning. Give it a run (just click on the image below to launch the sample, requires Flash Player 10):


LayoutSchematic

 

Initially you’ll see a vanilla Flex 4 dialog based UI. Push the ‘E’ key and the UI will transition to an interactive exploded view of the display tree. Push ‘E’ again to tuck things back where they started.

 

I’d imagine the approach would work with any 2D Flash or Flex content, though it really doesn’t make much sense with 2.5D centric apps. The basic idea is to just walk the display list and assign an appropriate z value to each depth level. I’ve offset siblings so they can be differentiated a bit, and injected a surrogate parent for the application so that I can adjust the registration point of the main application itself.

 

I have some ideas for use cases but I’d prefer to leave it to your imagination. The source is included in the SWF, please use at your own risk. If anyone feels like continuing to play with it please do, just let me know what other interesting ideas you come up with.

There are certainly bugs. When returning to the default 2D view for example, most nodes end up with zombie matrix3D instances, which cause Flex a few headaches and make the UI appear anti-aliased. As I have time I may toss a few fixes into the sample.

4 responses so far

Mar 25 2009

Some System.gc() and System.totalMemory Tips

Published by Corey under Technology, Work

When profiling a Flash or Flex application it’s sometimes useful to explicitly request that the player VM perform garbage collection. When used correctly this can help identify and track down memory leaks.

Some quick tips:

  • System.gc() is asynchronous! I can’t tell you how many times I’ve seen developers make the call to gc() and then immediately query System.totalMemory! I’ve also seen people call it twice in a row (just to make sure it sticks ??) . Internally System.gc() simply queues up a garbage collection pass for the next frame interval. So make sure you query totalMemory on the next frame (listen for enterFrame), or use callLater if within a Flex application.
  • System.gc() only works in a debugger player, and is a noop in the release build of the player. If you must do release mode profiling (which I highly recommend), you can utilize a well-known hack to force the player to garbage collect. Of course you do not want to make use of this in a production application, and the usual disclaimer applies, specifically this hack is not guaranteed to work in future versions of the player runtime.
     

    Keep in mind that the release mode GC hack is in fact synchronous, however in this case the internal player code also queues up additional collection for the next frame interval so it’s best practice to wait a frame even then, such that anything pinned in memory due to just being on the callstack can be cleaned up.

  •  
    1
    2
    3
    4
    5
    // Release mode gc().
    try {
        new LocalConnection().connect('_noop');
        new LocalConnection().connect('_noop');
    } catch (e:*) {}
  • System.totalMemory does not reflect all of the memory the player instance allocates. totalMemory is useful in most cases, since it reflects all of the memory that the internal player’s custom allocator has been asked to allocate for the bulk of the internal player constructs (inclusive of all script objects). Keep in mind however that not everything allocated in the player is allocated by the internal allocator, nor reported through totalMemory…namely anything allocated by OS system calls, memory associated with platform bitmap data, and the JIT buffer associated with the Actionscript VM.
     

    At times it’s useful to make use of other tools to glean the total memory used by the player. I recommend testing within a standalone release player and leveraging Process Explorer and its ‘private bytes’ metric when on Windows, or Activity Monitor’s ‘private memory’ metric on OS X. Steer clear of Task Manager, as it incorporates uncommitted virtual memory that may or may not be used and is lazily reclaimed by the OS.

     

    The next major release of the player will provide a new API which will more accurately reflect the cumulative memory in use by the player.

  • Not all players and SWFs are created equal. Memory usage of a debugger player rendering a debug SWF will be significantly higher than the same player rendering a release build of the same SWF. It also holds true that the memory usage of a debugger player rendering a release SWF will be significantly higher than a release player rendering the same release SWF. So long story short, it’s always best to do your profiling and performance testing in a release player (against a release SWF) when at all possible.

5 responses so far

Mar 25 2009

Player 10 Performance Gotcha - Sneaky Surfaces

Published by Corey under Technology, Work

When optimizing a production application, regardless of the SDK or technology used to build it, it’s important to understand the performance characteristics of the various APIs, primitives, and data structures that make up your SDK. When becoming proficient with a given platform it’s inevitable that you stumble upon nuances, inefficiencies, or just plain bugs…and over time your learn to “work with” (or around) said limitations.

Here’s one of the “plain ol’ bugs” you should be aware of when scrubbing your Flash or Flex application of performance issues.

Take the following code snippet towards the end of this post… Pretty simple, just creates a couple hundred Sprite instances, applies a quick opaque fill, and adds them to the stage. Taking a look at System.totalMemory, memory increases by about ~500K. Nothing mysterious.

Now, imagine we were to ask the player to cache each Sprite instance as a bitmap, e.g. via:

    currentSprite.cacheAsBitmap = true;

So for 250 display object instances, one would expect that the resulting ~ 3MB of memory usage sounds about right (32 bpp RGBA buffers). Again, nothing mysterious.

  

Now, let’s run the same test, but instead of setting cacheAsBitmap… what if we simply read the value of cacheAsBitmap for each Sprite instance:

    var test:Boolean = currentSprite.cacheAsBitmap;

Whoa! Again, we see ~ 3MB worth of surface allocations! For simply reading the property?!

Beware, this issue also affects a few other properties, some that may make it even more likely you’ll run into this… For example, simply asking a display object whether or not it has a scrollRect will cause a back buffer to be allocated for that object. Testing the opaqueBackground property also results in a similar fate.

Note: The problem as described currently affects the production Player 10 versions (10.0.12.36 and 10.0.22.87). The issue itself has been addressed and should be taken care of in the next non-incremental release of the player. Just tread lightly. :)


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
    creationComplete="updateMem()">
 
    <mx:Script>
    <![CDATA[
        [Bindable]
        private var totalMem:String;
 
        private function startTest():void
        {
            for (var i:int = 0; i < 250; i++)
            {
                var currentSprite:Sprite = new Sprite();
                currentSprite.graphics.beginFill(0x000000);
                currentSprite.graphics.drawRect(0,0,300,100);
                currentSprite.graphics.endFill();
               
                // Uncomment to allocate surfaces for each Sprite instance (+ ~3MB).
                //currentSprite.cacheAsBitmap = true;
               
                // Uncomment to (surprisingly) take the same surface hit (+ ~3MB)
                //var test:Boolean = currentSprite.cacheAsBitmap;
                //var test2:Object = currentSprite.scrollRect;
                //var test3:Object = currentSprite.opaqueBackground;
               
                canvas.rawChildren.addChild(currentSprite);
            }
            System.gc();
            callLater(updateMem);
        }
       
        private function updateMem():void
        {
            totalMem = String(System.totalMemory / 1024) + " KB";
        }
    ]]>
    </mx:Script>
 
    <mx:Canvas id="canvas" width="300" height="100" />
    <mx:Button label="Start Test" click="startTest()" />
    <mx:Label text="Total Memory: {totalMem}"/>

</mx:Application>

One response so far

Mar 24 2009

Improving Perceived Layout Performance in Flex

Published by Corey under Technology, Work

The Problem

For a typical browser-based Flex application, as the brower is resized by the end user, it’s very common to see the Flex content lag behind the browser frame. As the Flex app is resized very often you can see the Stage background paint, before the Application background can catchup.

Take the following example SWF (click to open):


Layout Sample

After launching the sample, resize the browser frame quickly left and right, and up and down from the bottom right corner of the browser chrome. You’ll notice that along the right and bottom edge of the viewport, the green stage background can be seen, as the content tries to keep up with the resize events. This “lag” is most commonly seen on Mac OSX 10.4 and later when running in the standalone Flash 10 player, Safari, or Firefox. On Windows, the lag is most commonly seen within the Firefox browser, but depending on your hardware configuration, can also occur in IE, AIR, and the standalone player.

The Solution

Whenever the player Stage is resized, the Stage issues a ‘resize’ event. In Flex, our top level Application object listens for the resize event. When it’s received Flex invalidates the display list, then queues up a layout request. Only later, when we eventually receive a ‘render’ event from the Stage, or an ‘enterFrame’ do we actually layout and update our display list.

Flash delivers stage resize events pretty much in lock step with the browser or parent container, but render and enterFrame events are tied to the player’s natural update interval. Since Flex waits until the following update interval to actually paint, we’ll always see this lag.

In the sample above, I’ve added a checkbox, which when enabled, demonstrates a smoother resize approach. Essentially we just ensure that we ‘validate’ our display list upon receipt of every Stage resize event. The solution is to ensure that when our root application is resized, that we follow suit with a validation (layout) as soon as we can, rather than deferring as is the typical case when child elements are resized on their own. Perceived performance can be greatly enhanced.

The Catch

Why don’t we make this change within the core SDK itself? Unfortunately, there’s a catch - an existing player bug we would have to work around, primarily on Windows. When the plug-in version of the player has its WMODE rendering mode set to “transparent”, or any other non-default value for that matter, display list corruption with TextFields can occur (specifically those using system text). When WMODE is set to transparent for example, and TextFields are present in the display tree, the raster representation of these text elements becomes visibly corrupt when they are moved and updated within a Stage resize event handler. A player bug is logged and the issue is being addressed.

In the mean time, if you know your interactive will never be using a non-standard WMODE, feel free to take the approach outlined. The results will be a much smoother, more responsive layout experience in most cases. Some cookbook code follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="utf-8"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    applicationComplete="appComplete();">

    <mx:Script>
        <![CDATA[
           
            private function appComplete():void {
                stage.addEventListener(Event.RESIZE, onStageResize);
            }

            private function onStageResize(e:Event):void
            {
                validateNow();   
            }
        ]]>
    </mx:Script>
</mx:Application>

2 responses so far

Feb 08 2008

Flight 404

Published by Corey under Art, Technology

Today I learned:

  • Flight 404 is back!

I have been interested in generative art (art generated by code) for as long as I remember, and Flight 404 was always one of my favorite websites. I hadn’t checked for anything new until just today. Boy am I glad I did. Amazing stuff. Read about the process if you are interested… (part One, Two, and Three).


Magnetic Ink, Process video from flight404 on Vimeo.


As far back as I can remember Robert Hodgin did most of his work in Flash and Flight 404 was primarily used as his portfolio. For awhile now Robert has been dabbling in the Processing library for most of his experiments. Here’s another of his creations. Check out his blog for lots more!




Solar, with lyrics. from flight404 on Vimeo.

5 responses so far

Feb 07 2008

Subscription Based Toilet Paper and Astronauts

Published by Corey under Life

Today I learned:

  • You can now purchase a subscription for toilet paper!
Toilet Paper

Werner Vogels, CTO of Amazon, spent a good two hours with us today, giving a high level overview of Amazon’s adoption of grid computing and cloud computing infrastructure. Quite enlightening given Adobe’s current reliance on a legacy ‘cluster’ model for our first generation SOA applications.

Werner was kind enough to clue us into the fact that Amazon, always the innovator, now provides not only a vast selection of toilet paper, but a subscription based model as well! There’s even an eco-friendly, 2-ply toilet paper made out of recycled material. Pleasantly surprised customers, having discovered that the toilet paper has a “rough” side and a “quilted-side” have even provided in depth ratings. You can purchase a twenty-pound 48-pack 500 sheet rolls, or subscribe to the same amount on a monthly or bi-monthly basis.

(Sorry…no gift wrapping available for this item however…)


  • The San Jose California “Mounted Police” have a sense of humor.

Taken at a local coffee shop where a pair of officers stopped in for tea and pastries earlier this afternoon…

Coffee Break


  • Urinating on the back tire of a transport bus prior to liftoff is a tradition of Russian astronauts.

Charles Simonyi participated in a panel on domain specific language and parallel computing. The former head of Microsoft’s application software group, now CEO of Intentional Software gave us his take on Technology futures, and then pulled out his amazing photo-album from his trip into space. Charles has the distinction of being the fifth paying space tourist in the world (and the 2nd Hungarian in space ever).

Charles told several amusing anecdotes of his time with the Russian Federal Space Agency, but perhaps the most interesting was that on their way to the launch pad his transport vehicle pulled over and everyone got out, unzipped their space suits (which had previously been hermetically sealed by the launch crew in front of the press and visitors) and proceeded to urinate on the back tire of the van. Charles naturally joined in and also partook in a last minute smoke, while the launch crew (who accompanied the team on the bus), re-sealed their flight suits. The last minute smoke a safe distance from the launch ready rocket clearly made sense, but relieving themselves at the side of the road?

Ah, good old Ruski tradition apparently. In 1961, Yuri Gagarin, (the first human in space), stopped to empty his bladder. The act became a tradition with subsequent cosmonauts, who urinate on the back tire of the transport bus before their flights. I still can’t figure out the significance of the back right tire though, perhaps an homage to the first cosmonaut in space?..the Russian dog Laika?

One response so far

Next »