There are a few new graphics classes in the Flex 3 SDK that make it easier to create image snapshots of Flex UI components. The ImageSnapshot class provides some static methods for creating snapshots of components and encoding them as PNG or JPEG images. In addition to the ImageSnapshot class, we also get the PNGEncoder, JPEGEncoder, Base64Encoder, and Base64Decoder, which were all previously in the as3corelib project.

mx.graphics.codec.JPEGEncoder
mx.graphics.codec.PNGEncoder

The JPEGEncoder and PNGEncoder classes were in the as3corelib project prior to Flex 3. They have since been rolled into the main Flex framework. Nice! They’re pretty straightforward, and they’ve been around for awhile in the as3corelib project, so they shouldn’t need much explanation.

mx.graphics.codec.IImageEncoder

The IImageEncoder interface defines an interface for a class that encodes a BitmapData object or the raw bytes of a Bitmap into a new encoded ByteArray. The two classes that implement this interface are PNGEncoder and JPEGEncoder. If you were to write your own image encoders you could implement this interface and then you could pass your custom encoder to ImageSnapshot.captureImage() (read below for more on that).

mx.graphics.ImageSnapshot

The ImageSnapshot class is a new addition to the Flex SDK that simplifies the process of capturing an image from a Flex UI control. This is a task that is often performed, I can think of a bunch of examples right off the top of my head where I’ve had to do this. A live reflection class is one candidate to use this new helper class. I have a feeling a big use of this class is going to be saving image snapshots to the user’s computer in an AIR application. And another use-case that I recently dealt with is converting a Flex UI component to a Base 64 encoded image (see my previous post).

When I needed to get a Base64-encoded string of a given Flex UI component I did something like this:

private function getBase64String(component:UIComponent):String) {
	var bitmapData:BitmapData = new BitmapData(component.width, component.height, true, 0xffffff);
	bitmapData.draw(component);

	var bytes:ByteArray = PNGEncoder.encode(bitmapData);

	var b64encoder:Base64Encoder = new Base64Encoder();
	b64encoder.encodeBytes(bytes);

	var b64String:String = b64encoder.flush();
	
	return b64String;
}

But now we have a much easier way. The ImageSnapshot class has a few static methods that we can use. We get:

captureBitmapData
This is the utility function that returns a BitmapData object. This basically saves us a line of code and simplifies the call. Dimensions are capped at 2880 pixels for each side.

captureImage
This returns an ImageSnapshot object. That doesn’t get us all that much, but there are a few pretty cool things. We can pass captureImage a parameter that tells it how to encode the image. PNGEncoder and JPEGEncoder have been rolled into the framework now, so we can pass in either of those and it will encode the image as a PNG or a JPEG.

Once we get the ImageSnapshot object that the static method returns then we can access the byte data of the encoded image with the data property. Then we could pass the JPEG or PNG encoded image to a server to save the file, or if you’re writing an AIR application you could save the file to the hard drive (or drop it onto the clipboard).

encodeImageAsBase64
This function takes an ImageSnapshot object and encodes it as a Base 64 string. Easy enough.

So to go back to the sample code above, now we can generate a Base 64 encoded string like this:

private function getBase64String(component:UIComponent):String) {
	var snapshot:ImageSnapshot = ImageSnapshot.captureImage(component);
	var b64String:String = ImageSnapshot.encodeImageAsBase64(snapshot);

	return b64String;
}

and if you’re too good for three lines of code:

private function getBase64String(component:UIComponent):String) {
	return ImageSnapshot.encodeImageAsBase64(ImageSnapshot.captureImage(component));
}

Bypassing the 2,880 pixel limit
Flash Player has a limitation of only allowing a single bitmap object to have a max width or height of 2,880 pixels. I’ve never run into this problem, but I guess people with massive monitors can have a problem. The ImageSnapshot class does some fancy footwork in the captureImage method that allows you to generate an encoded JPEG or PNG snapshot that is larger than 2,880 pixels. Basically it creates multiple BitmapData objects and stitches them together to form one final ByteArray. Look at the source code for ImageSnapshot and check out the captureAll method.

This gets around the 2,880 pixel limit, but there’s a 256 meg size limit on a single ByteArray object. From the documentation in the ImageSnapshot class: “This ByteArray is limited to around 256MB so scaled images with an area equivalent to about 8192×8192 will result in out of memory errors.”

So nothing groundbreaking here, but we get to save some boilerplate code that we used to have to write to generate a BitmapData object from a Flex UI object, or to generate the bytes of an encoded JPEG or PNG image. I’m guessing a big reason for Adobe including this in Flex 3 is to make it easier to save JPEG or PNG snapshots of charts in an AIR application.

I’ve set up a project using Trac (if you don’t know what trac is read here) that allows you to compare the source code of the new beta release of the Flex 3 SDK with the previous Flex SDK 2.0.1 version. This lets you browse all the changes that were made and visually see the differences. I find this very useful when trying to analyze the new release and figure out what the new additions and changes are.

Here’s a link to the main Trac website.

You can view the entire changeset from version 2.0.1 to version 3 here. (Warning: it’s pretty big so it might take a bit to load).

If anyone from Adobe doesn’t like this and wants me to take it down just let me know. I think it’s valuable for the development community, but if you’ve got a legal fever and the only remedy is to yell at me, then I’ll remove it. Email me here: doug@dougmccune.com.

This post discusses the features Ted Patrick blogged on Wednesday: the Advanced DataGrid component, Deep Linking, Resource Bundles for localization, and the Flex Component Kit for Flash CS3.

Advanced DataGrid (I would’ve called it SuperDataGrid)
This is basically what the community has come to call a “TreeGrid”, plus the addition of more control over the headers, and summary rows and cells. It’s certainly a component that has has been asked for like mad. I’ve seen a few versions of a TreeGrid component out there (like the one in FlexLib). As far as I know this component’s a hard one to get right, I know the FlexLib version has quite a few issues, so it’s good to see that Adobe’s been working on a solid version themselves. I’ll be interested to dive in and see how they did it (ie I assume DataGrid as the base, but do they use the Tree control? or did they cook up an independent Tree control for use within the DataGrid? Is the original DataGrid component untouched?). I’ve never seen anyone add summary rows to the DataGrid component, but I’ve heard people request this a lot, so I’m sure this will get a lot of use as well.

I’ve said before that the DataGrid stuff doesn’t get me excited. This is a component lots of people have wanted, so that’s cool, and I bet I’ll find a use for it (like in my AS code analyzer app for sure), but if this never existed I wouldn’t cry myself to sleep. It’s a cool and requested component, but I mean, that’s what we get for UI components? Two layout components and a better DataGrid? I know a couple people on the SDK team, they’re smart, they can make really cool shit (I mean, the Flex 2 SDK was frickin amazing). This is what they’ve been spending their time on since the release of the Flex 2 SDK? Bugfixes and a DataGrid? Being a component developer on the Flex 2 SDK seems like it would’ve rocked. Flex 3 SDK? mm, not so much.

Granted, we’ve had some good components come out of Adobe (or Adobe Consulting) since the release of Flex 2, like the Scheduling Framework, Auto-complete TextInput, Docking Toolbar. And Ely Greenfield has put out mindblowing stuff. So in my ideal bountiful-component world? Take Ely and get him working with Alex Uhlmann and the rest of the Adobe Consulting peeps to crank out components. The amount of stuff they could put out in a year would be amazing. Ely, you hear that? Enough management and planning, stop writing specs, take a pay cut and demotion and start writing code again!

Deep Linking
That’s cool, I don’t know if any of the apps I write will use deep linking, but it’s good that it’s available and easy to use. But most of the discussion around deep linking is about SEO. An important part of deep linking support is that Flex/Flash apps need the ability to present multiple unique URLs to search engines for them to index. The inclusion of deep linking on its own doesn’t address the SEO issue. So just because you might be able to have unique URLs for the different parts of your Flex app doesn’t mean that Google is going to include your URLs in its index. Now I’m not saying that Adobe doesn’t know this, that link at the beginning of the paragraph is Matt Chotin asking the Flex community if deep-linking on its own, without SEO, is still valuable. So clearly Adobe has decided that even though there is still no solution for SEO with Flex apps, they’re going to support deep linking. That’s good and all, but what would have made this a show-stopper is if the announcement was that Adobe had worked with Google to make Flex apps indexable. Now that would be impressive.

Resource Bundles and Runtime Localization
I know this has been often asked for. Basically at every public Q&A session with people on the Flex team that I’ve ever been to (Apollo Camp, 360 Flex, some of the silvafug meetings) someone has asked about localization and multiple language support. So the demand is clearly out there. I don’t have any experience trying to make apps that support multiple languages (what, not everyone speaks English? really?). So I can’t say that this eases a distinct pain of mine, but I know it’s important to a lot of people, so kudos to Adobe for getting it rolled out. It doesn’t make Flex 3 stand out in my book, but I know this feature alone will make the upgrade worthwhile for some.

Flex Component Kit for Flash CS3
This was sort of mentioned in Ted’s previous post when he talked about skinning integration with other CS3 apps. I haven’t tried this out, and I actually have a pretty pessimistic view whenever I hear talk about cross-product integration. But if this works I will probably do a lot more skinning in Flash. A personal aside, I started working with Flash before I started working with Illustrator. I’m not a great graphic designer, but I enjoy design and skinning and all that. I actually like the simplicity of the Flash vector drawing tools. When I skin apps (or even make t-shirts, or stickers, or whatever) I often draw my graphics directly in Flash. Illustrator lovers will probably gasp at the fact that I like drawing in Flash more, but hey, I’m a simple guy. So since most of the vector graphics work I do is already in Flash, that means I can designs skins using the app I’m most comfortably drawing with (as opposed to Fireworks). I don’t do enough skinning work to make this too important, but if the Flex Component Kit works well (I haven’t tried it yet) then this might be pretty sweet for me.

Summary
This feature set is all about the Advanced DataGrid component. This is a component a lot of people have wanted. But I’m about as excited about this one as I was about the original DataGrid or Tree components in the original Flex 2 SDK (that is to say, not excited much at all). I think the main reason I’m so down on the Advanced DataGrid is because I saw Flex 3 as an opportunity for a whole set of new component toys to play with. And so I wonder how the same team of programmers who put together the first Flex 2 SDK can put out an update that includes a whopping 1 new UI component and 2 layout components. This does not include updates to the charting components that will also be included, I have no idea what those will be, maybe I’ll be blown away (although I’m only expecting minor updates to existing charting components).

The announcement that Ted made today about Flex Framework caching on the client is more exciting to me than this feature set. I’ll try to write up my thoughts on that tomorrow when I get time. I think it’s an important feature (although not as important as the Profiler). But I’ve never seen the 500-700k footprint of a Flex app be a show stopper. But anything to get that large SWF size down will give Flex haters a bit less to argue about.