Native Image Encoding API's - BitmapData to ByteArray (PNG,JPG)
DIGG IT!
42
Comments
Published
Saturday, May 31, 2008
at
6:53 AM
.
Reading the comments on my blog post on CURL BenchMarketing I might be very wrong about the market need for native image encoding. I would like to better understand the need for this as a feature and gather feedback from the community.
Image Encoding Feature Request
Encode a BitmapData Object to PNG, JPG ByteArray with a native API.
Example:
import flash.image.JPEG;
import flash.image.PNG32;
myJPG:ByteArray = new JPEG( bitmapData , 300, 300, 80 );
myPNG:ByteArray = new PNG32( bitmapData , 1500, 1260 );
Formats: PNG, JPG
Focus in order of importance:
- Performance of the translation
- Quality of the Encoding to PNG, JPG Standards
As Flash Player 10 supports writing data to the local machine, Image encoding may become a bottleneck feature for many customers. As data no longer needs to traverse the network for security purposes, it makes sense to allow easy creation of native image formats in Flash Player and AIR.
If you would like to see a feature like this implemented within Flash Player, please post your name, company, and thoughts in the comments below.
Cheers,
Ted :)
CNET Networks in San Francisco has a great opportunity for a software
engineer in our data warehouse group. Here is a link to the job
description.

You can apply directly via the link, or contact Hilary Straw directly at 415-344-2371
CNET on Flex!
Ted :)
CURL released a language performance benchmark and press release highlighting how much faster their language is than ActionScript 3. At first glance it seemed very impressive, 8X faster than ActionScript WOW but looking deeper this is mostly irrelavent. The first thing that struck me was that the benchmark was for encoding a JPG image, not rendering it or uploading it but iterating over each pixel and translating it to another image type, JPG.
Here are my issues with this:
1. Name a single mainstream RIA that encodes a JPG?
Uploading a JPG - Important
Rendering a JPG - Critical
Encoding a JPG - Not essential
We support Encoding in the Flex Framework to allow image conversion but it is far from a mainstream feature. It is an API that is useful on projects where one needs to convert from the native DisplayList BitmapData format to other web image standards like PNG, GIF, JPG.
Flash Player supports imaging directly in the runtime so you can create images from any content in the Flash Player as native objects. There is no need to encode these as JPGs EVER and the speed is lightening fast actually it is far faster than any of the CURL results by an order of magnitude.
2. How much market reach does CURL have? Are they installed on 50%, 40%, 30%, 20%, 10%, 5%, 1% of computers?
The ability to run applications seamlessly without installing anything is the key to Flash Player's adoption for RIA's (one use of many). Flash Player 9 is installed on over 98% of computers. Flash Player 9 is on 98% of computers!!! I have NO reach statistics for CURL but they are not even on the radar! NOT ON THE RADAR!!! (Maybe that is why they needed to do a press release)
3. Code execution - There are a ton of dependencies in benchmarking and I know for a fact that you can make small changes in code will yield dramatically faster code execution. For instance in Flash Player 10 we added support for Vector (Typed Arrays) and simply swapping an Array for a Vector can result in 20X performance gains when iterating over data. The fact is that Flash Player is wicked fast and as computers increase in performance the gains are seen in the shipping Flash Player.
I keep seeing other runtimes benchmark against Flash Player but they do so within the performance vacuum and do not take into account reach, rendering performance, cross-platform, and compatibility aspects. Every developer wants to use the fastest language but the reality is that the language most compatibly installed eventually wins out. Both JavaScript and ActionScript are gaining adoption rapidly because they are widely available, not because they set land speed records for image encoding.
If I was choosing a runtime to bet my business on, I would bet on Flash Player because end users do not have to install a thing, it just works. That is not true with CURL, GEARS, Silverlight, and JAVA. Next time you see someone touting that they run faster, ask them what % of machines is that runtime compatibly installed on today.
Duhhhhhhhhh... Flash Player it just works!
Ted :)
Mozilla is attempting to set a world record for downloading FireFox, good luck with that! The problem I see is that Adobe Flash Player has seen installation spikes daily that go into the 14 Million to 25 Million per day range. We report averages on all our player stats but never the spikes in traffic. It makes me think that we should be much more open about our download statistics regarding Flash Player.
Maybe we should just just submit Adobe Flash Player installs for the World Record and resubmit it as spikes occur.
Although even this gets sticky. If they count Mozilla FireFox 3 downloads according to file size, each download is 12MB average (MAC/WIN/LIN) where Flash Player is far smaller. It gets even worse when you think about auto-update a download, I am sure the OS teams at Microsoft Update see lots of issues.
Too fun!
Ted :)
As an ecosystem we do not share knowledge very well and over time this has essentially created a very large walled garden. If you are in-the-know regarding the ecosystem or sub-segment of it, you can see all the value clearly and know where and how to get what you need to succeed. If you are outside the wall (new to Adobe tools and technologies), you see a very large intimidating wall that looks proprietary at first glance.

I don't think anyone in Adobe had a vision of building a large wall that looks proprietary but alas here is this wall and behind it is an ocean of knowledge on how to make great experiences. Actually we have spent a great deal of effort to tear down the wall around our runtimes and core technologies with Adobe Labs, Open Source Flex, Blaze DS, Bugs.adobe.com, Open Screen Project, and Tamarin but we still have a vast quantity of knowledge in the community that is not shared.
I believe that the root cause is actually that a majority of our output is compiled and thus the source code and context remains hidden from view. View Source in the browser really enabled anyone to learn HTML/JS and this "forced sharing" makes it feel much more open. SWF on the contrary is a dark magic and how it works and how to make it do amazing things is not shared automatically. It SEEMS closed and proprietary because the source code is not present and thus the knowledge and context behind great projects are by default locked into a vault. On one hand it is really great that these formats are compiled but on the other we must do extra work to share knowledge. I believe that the "lack of sharing" is the subtle gravity that is holding back our ecosystem and that if Adobe made it easier to share knowledge we would move dramatically forward, actually violently forward.
There are some large projects underway at Adobe, "ION" and "Hyperdrive", to tear down these walls and force knowledge into the open. I am looking forward to working on them with you and helping the community share knowledge more openly, more easily. I also want to make sure that anyone sharing knowledge gets full credit for their contribution and that value flows towards those that share in the community.
Back to tearing down this wall...
Details coming soon!
Ted :)
On May 1 I passed my 2 year mark at Adobe and I took some time off to think very deeply about what I wanted to focus on moving forward. The thing is that I am very passionate about helping developers succeed and have found myself selecting projects related to training (Yahoo & Google) and events (Adobe MAX, Adobe Engage, 360Flex, Etc). Effective this week I will be migrating from Technical Evangelist to focus on scaling Adobe's events and training in the Platform Business Unit. The change is a great opportunity for me personally and I really believe that we can grow the developer ecosystem/market dramatically with some key changes to our event and training strategy.

The thing is that I will never stop evangelizing; I was passionate before I joined Adobe and I remain so as I change roles within. I will keep on blogging too and with all this "Thermo" and Flex 4 stuff coming I have an endless supply of material to cover.
Now go register for MAX 2008!
More to come!
Ted :)
Looks like Dell has been working with Flex 3. These widgets are confirmed Flex 3.
http://www.dell.com/content/products/category.aspx/desktops?c=us&cs=19&l=en&s=dhs
http://www.dell.com/content/products/category.aspx/notebooks?c=us&cs=19&l=en&s=dhs
Go Flex!
Ted :)
I started FlexJobs in Jan of 2007 and the list for Flex related jobs has been growing steadily. After returning from my vacation there were 35 new jobs to review and post and it seems that the subscribers jumped to over 1000.
http://tech.groups.yahoo.com/group/flexjobs/
To subscribe send an email to: flexjobs-subscribe@yahoogroups.com
Cheers,
Ted :)
ILOG Elixir - OEM Licensing Changes!!!
DIGG IT!
1
Comments
Published
Tuesday, May 20, 2008
at
7:18 AM
.
Since posting on Elixir Flex Components, the ILOG team has gotten a steady stream of feedback on OEM licensing. Today ILOG removed the OEM restrictions for small business and start-ups.
I have really been impressed with the quality of these 3rd party components and seeing as the only negative feedback was the OEM licensing restrictions for smaller firms, this change is a welcome addition. I keep seeing these components pop-up in applications and I am sure they will get more use with this licensing change.
Licensing FAQ
Cheers,
Ted :)
Google Maps Flash API - Distributed components/services
DIGG IT!
5
Comments
Published
Monday, May 19, 2008
at
10:52 AM
.
Google, yes, Google released a pure AS3 Mapping engine last week while I was on vacation. With all the Flash Player 10 news it was not seen by many and essentially overlooked. It is really great to see Google Maps leverage ActionScript 3 and even more exciting to understand the architecture they chose. The Google Maps Flash API is the first major component to work distributed as the core logic remains on google servers and the API you program with is just a simple proxy loading the remote SWF and that SWF talks back to Google to get data and tiles as a service. This has some very distinct benefits:
1. Updates - With the Google Maps API, Google can fix core bugs or add features without requiring an updated developer API. It also requires no changed to sites that have deployed the Map engine.
2. Security - The security model of this component model allows for more fine grained control over use of the API and services. Currently the API support developer keys and restricts use to a domain. This is essential if you wanted to put more valuable services in like ads or maybe pay a website owner using an AdSense like model.
Seeing Google explore using Flash Player and AS3 as a distributed model for services is exciting. As Google is primarily a service based company (search, ads, email, news are all services) I am sure we will see this core architecture leveraged for many other properties.
Google Maps Flash API
Basic Turtorial
Examples
Example Source
Congrats to the Google Maps team!
Ted :)
I have been offline for the past 10 days and my blog has been a bit too quiet. I missed the Flash Player 10 Beta, a ton of MAX meetings, and probably something urgent in the office but sometimes you just need to take a break. On this trip I really unplugged and did some amazing things:
1. I got engaged to Linda while here in Hawaii! I surprised her on the beach on May 10 after watching the sunset. She has really changed my life and she is easily the best thing to happen to me in a long long time.
2. I completed 20 Sudoku puzzles correctly averaging about 2 per day. I am an addict thanks to Keith Peters!
3. I finished a great book The Milkshake Moment.
4. 3 dives, 5 eels, 5 turtles, 3 sharks, fish, coral, the works. w00t, go diving!
5. Mama's Fish House - If you are ever in Maui, you must must must eat here.
(Extra points as their site uses Flash)
The week has been really great and allowed me time to reflect on my work and life. It is really great to work for a company that encourages taking time off and recharging the batteries. May 1 was my 2 year anniversary at Adobe and time has literally flown by. Looking back on the past 2 years is really amazing, from the launch of Flex 2.0, 2.01, and Flex 3 I have been very focused on technical evangelism. As I return to San Francisco I will begin a new role at Adobe and honestly I am really excited to get started. I will keep you in the loop on the change, it is a good thing.
Cheers,
Ted :)
It seems amazing to me that camera prices have fallen so rapidly yet the cameras are capable of so much more. I am headed on vacation this week and decided to get a new point and shoot camera. Shockingly the same Panasonic Lumix camera I paid for 2 years ago costs 70% less and actually has more features. In the small I got an inexpensive 8MegaPixel camera but in the large I am wondering about the overall market effect of commodity low cost high capacity digital devices. I think we are seeing the arrival of the real digital era where everyone is transferring high quality images using very low cost devices. Add a 2GB memory card to this for $24 and I have a really great camera setup for under $200, scary.
The digital tidal wave is arriving.
It is also cool to think that these same cameras might one day be programatic and run Flash via the Open Screen Project. Fun Fun!
And now PhotoShop Express allows you to edit your Flickr images.
cheers,
Ted :)
Next Dreamweaver - A killer app for HTML/JS/AJAX
DIGG IT!
12
Comments
Published
Thursday, May 08, 2008
at
1:44 PM
.
Every once in a while I peek over the fence to see what the HTML/JS camps at Adobe are working on and was I in for a suprise. I really believe that the next Dreamweaver release is a killer app for HTML/JS/AJAX design and development. It is rare for me to label something a killer app but I have never seen first class tooling for html/js like this before.

The team has made several key product decisions, embedding Webkit, that have resulted in some amazing features and workflow for building web pages (dare I call them that anymore). I visited with Scott Fegette and he briefed me on what they were working on and showed a demo he did at Web 2.0 recently. In the demo he previewed a page and then paused JavaScript allowing you to both see and edit the current DOM in place. It is hard to explain but it is like FireBug on steroids and made editing very complex interactivity very easy. The puzzler is that this is just 1 of many new features and workflows for both developers and designers.
More to come!
Ted :)
Verizon just released a new Flex 3 application for selling ringtones and ringbacks. The site is excellent and the use of transitions and dynamic data is visually stunning. It is one of the best Flex apps I have seen in a while. It also is also one of the first full ecommerce experiences in Flex that I have seen. You can search, preview, and buy any ringtone or ringback on Verison online. Way cool!
VERIZON MEDIA STORE

Cheers,
Ted :)
The Wiki over at opensource.adobe.com is in full swing and recently the States enhancements were posted here I really like the changes as states were so complex to think about and edit without the design view. The new inline States allow you to declare state changes within components using a simple syntax and some new attributes. Before you had to define all the delta values externally within a state tag and this was very hard to edit by hand. Here are a few examples:
Inline States Syntax ( Note use of "includeIn" and "excludeFrom" ):
<!-- Given the states A,B,C -->
<m:states>
<m:State name="A"/>
<m:State name="B"/>
<m:State name="C"/>
</m:states>
<!-- This button will appear in only states A and B -->
<Button label="Click Me" includeIn="A, B"/>
<!-- This button will appear in states A and B -->
<Button label="Button C" excludeFrom="C"/>
State specific attributes:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="library:ns.adobe.com/flex/halo"
xmlns:m="http://ns.adobe.com/mxml/2009" layout="absolute">
<m:states>
<m:State name="landState"/>
<m:State name="airState"/>
<m:State name="waterState"/>
</m:states>
<mx:VBox id="vbox">
<mx:HBox>
<mx:Button id="land" label="Land" click="currentState='landState'" />
<mx:Button id="air" label="Air" click="currentState='airState'" />
<mx:Button id="water" label="Water" click="currentState='waterState'" />
</mx:HBox>
<mx:CheckBox label="Helicopter" color.airState="0xFF0000"/>
<mx:CheckBox label="Motorcycle" color.landState="0xFF0000" />
<mx:CheckBox label="Car" color.landState="0xFF0000" />
<mx:CheckBox label="Airplane" color.airState="0xFF0000"/>
<mx:CheckBox label="Train" color.landState="0xFF0000" />
<mx:CheckBox label="Boat" color.waterState="0xFF0000"/>
<mx:CheckBox label="Submarine" color.waterState="0xFF0000"/>
</mx:VBox>
</mx:Application>
Object Based Properties:
<mx:Application xmlns:mx="library:ns.adobe.com/flex/halo"
xmlns:m="http://ns.adobe.com/mxml/2009">
<m:states>
<m:State name="default"/>
<m:State name="glow"/>
</m:states>
<mx:Button label="Button" click="currentState=currentState=='glow'?'':'glow'">
<mx:filters>
<mx:DropShadowFilter distance="9" />
</mx:filters>
<mx:filters.glow>
<mx:GlowFilter/>
</mx:filters.glow>
</mx:Button>
</mx:Application>
<!-- Alternatively the above code could be written using
state specific nodes -->
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:m="http://ns.adobe.com/mxml/2009"
xmlns:mx="library:ns.adobe.com/flex/halo">
<m:states>
<m:State name="default"/>
<m:State name="glow"/>
</m:states>
<mx:Button label="Button" click="currentState=currentState=='glow'?'':'glow'">
<mx:filters>
<mx:DropShadowFilter distance="9" includeIn="default" />
<mx:GlowFilter includeIn="glow"/>
</mx:filters>
</mx:Button>
</mx:Application>
I especially like the simplicity of the new states. States were a very hard feature to use larger scale but the changes in Flex 4 really look to be a step in the right direction. I guess the more obvious thing for me is how open we are about sharing key information on a release so far in advance. We have done alphas before with Flex but being able to see inside of the early prototype stages is very cool. Trust me when I say that there is a ton more to come.
Cheers,
Ted :)
Thank God, the new feeds.adobe.com is up!! It was like someone had turned off the air. Special thanks to the team that put in a ton of work on getting feeds.adobe.com. I know Daniel Taborga, Lily Lee, Christian Cantrell, Mike Chambers, Ben Forta, Jonathan Wall, and many others worked hard to make this happen. Also the time frame for this massive architecture change is really impressive. To go from a single server to 7 inside of 2 weeks time is really amazing.
Here is the new architecture:
1 - Load Balancer
5 - Apache + CF8 Clustered
1 - Database Server MYSQL
1 - Feed Aggregation Server (reads all RSS and populates database)
vs
1 - CF6 + MYSQL + Apache

Thanks for being patient during the downtime! 7 times as many servers are running feeds.adobe.com so hopefully downtime is a thing of the past.
Cheers,
Ted :)
Open Screen Project and Duran Duran
DIGG IT!
9
Comments
Published
Saturday, May 03, 2008
at
9:22 AM
.
Last night my girlfriend Linda took me to see a Duran Duran concert in Concord. It was a funny flashback to the 80's and aging rock stars aside, it was great fun. At one point in the concert the band went into a slow song and the lights dimmed causing the audience to pull out their phones and a few remaining lighters. The thing that struck me was there was a single computer on stage, an Apple MacBook Pro, and easily 5,000+ phones in the air. That really hit me and seeing so many programmatic devices with a user interface was really stunning.



To say it isn't drop dead essential that Flash Player and AIR support these screens is an understatement. It is a massive opportunity to release the creativity of the Adobe design and development community on making these screen experiences better.
5,000 screens vs 1 computer
Open Screen Project
cheers,
Ted :)
It is really great to see Adobe open up and todays announcements on the Open Screen Project are nothing short of revolutionary. There are tons of screens out there and today we removed the key barriers to seamless compatibility for any screen, TV, Mobile, Computers, Consoles, DVR's, and all the rest. Developing content for devices is very hard and often the licensing for device runtimes is a huge barrier to use. In removing the barrier for device porting, protocol and format use, and use of the spec to create alternate runtimes it allows Flash Player to reach much farther. It also opens the door to the larger task of format standardization.

The way I see it Adobe/Macromedia was a self contained ecosystem and with the Open Screen Project we are tearing down the walls allowing the garden to escape and grow wildly. The web is going to get much richer, more interactive, more collaborative, and much more fun as a result.

It is a great time to be an Adobe designer and developer!
Go Flash Go!
Ted :)
