Andrew Trice had a post over on InsideRIA about using Degrafa as an item renderer within a Data Grid to create a bar chart like effect. His post really helped show just how simple it can be to use Degrafa for visualizing data. In his example he used some RegularRectangles and bound them to the data that was being pulled into a single column to change the width of the rectangle. This was a very simple, yet effective approach and much nicer than looking at a long list of values.

We extended Andrew’s example a bit into another Data Grid example that uses an item renderer with a split bar visualization and optimized the example a little. This example could be extended even further by using Bitmap or Complex fills based on the data, or changing the shape used for the visual. Here’s what it looks like:

While syncing in iTunes I was looking at the indication of how my media was distributed across my iPhone and realized that same visualization could be duplicated using Degrafa. I used a series of different colored RegularRectangles, some VerticalLineRepeaters for the inset markings that dynamically change count depending on the size, some other Rectangles for highlights and shadows, and a RoundedRectangle to mask the area. I also through in a ComplexFill composed of a Solid, Bitmap and Blend fill to create the colored plaid effect. This was really easy to do with binding to change the width, capacity bars, inset marks and colors. Here’s what the example looks like:

UPDATE: Here’s another example that expands upon the bar charts above to create some shape based renderers and a pie chart renderer. The shape renderers were easy to do. They’re masks created with Repeaters. The stars are Polygon Repeaters, the circles are Circle Repeaters, and the squares are Rounded Rectangle Repeaters. The pie chart renderer is just a couple of Elliptical Arcs. See below:

These examples are available on the Degrafa Samples page with View Source enabled.

There’s so much data flying around out there that would be kinda neat to create unique visualizations for using Degrafa. I’ve been checking out COLOURlovers, Echo Nest, FriendFeed and more that would be cool to try and visualize or use in a visualization. Better yet, you could make certain properties accesible to a designer for them to make the visualizations customized to their specifications.

One of the benefits Degrafa offers as part of the framework is the ability to repurpose code to no end. This may be obvious for things like geometry, but if you find yourself writing redundant code for fills and strokes, this tip should help.

Rather than specifying the same common fills and strokes in every MXML file where you’re doing your drawing, you can separate fills and strokes in to their own MXML files. Then, whenever you need to access a fill or stroke, you can add that component to your MXML file and easily access them when appropriate. By doing this, you also have the advantage of code hinting, which makes for quick and easy coding.

As an example, I could make a Fills.mxml file where I specify a fill, like this:

Then, I can reference that MXML file wherever I’m drawing with Degrafa. For example, the following Circle.mxml code would reference the Fills.mxml:

Those two code samples represent some of the basic methods for cutting down on the amount of code you need to write. I could reference that Fills.mxml in any other component and use the fills defined in that file. You could do the same for strokes as well or make separate MXML files for each type of stroke or fill. It’s up to you. I put together a more evolved example than what was shown above and you can view it here:

View External Fills and Strokes Example
(View Source enabled. Also available on Degrafa Samples page)

Taking This Further

You can expand on this example by making separate Fills and Strokes files for different parts of an application, share those files with other Degrafa users, adjust the structure for what makes most sense for you, etc. One thing that would be interesting is to make a separate Colors class that you can reference from the Fills and Strokes files. Then, when you change the color values in the Colors class the whole scheme of the app could change. Hook that Color class up to a color API like Kuler or COLOURlovers and you could get some really unique opportunities for custom UIs, data visualization, compositions, etc.

We’ve been thinking about a way to grab a color palette using a color API, present a user with a bunch of variations of Fills and Strokes based on that selected palette, allow for selection of which Fills and Strokes the user wants, then write out MXML files with those selections in it. The user could then drop those MXML files into their Flex project and they’re ready to go. It could work the other way too where a user could read an MXML file and be presented with Fill and Stroke swatches of which they can edit and write out a new MXML file.

The more we keep plugging away on Degrafa it seems there are more and more opportunities for creating some really unique tools. Imagine a Fills and Strokes palette that uses the Fills and Strokes MXML files as the model. Who knows what other kinds of things people will come up with as the framework progresses. Any suggestions?

Last week I spoke at the Rocky Mountain Adobe Users Group about Degrafa and someone asked if I would go back and do a full session about the topic. They also asked how I would feel about making it a Connect session for anyone else interested could participate remotely. I thought would be great idea.

There are so many thinks that you can do with Degrafa and it’s evolving every week. Having a Connect Session would enable us to expose a lot of these features to a wider audience as long as there is a demand. So, I’m asking, is there a lot of interest in this? What areas do you have the most trouble/questions with? Any specific topics you’d like to see covered? I could also record the session and post it after the fact.

A lot of people we’ve talked to have been interested in using Degrafa for mapping. Of particular interest was drawing states or regions that incorporate events and data. We put together a proof of concept a while back for EffectiveUI and we’re now making the source available after some clean up and updates to the latest beta release. The sample uses Degrafa to draw the states and for some custom skinning.

There were a number of people on the Degrafa Group asking for the source, so we’ve enable “View Source” on the application. This sample is also available on the Degrafa Samples page.

View The Degrafa Map Sample

New samples of Degrafa in use can be found at http://samples.degrafa.com. If you attended the Degrafa session at 360|Flex you may remember seeing them. They all address some of the new features in latest beta and include samples for:

• Skinning a VSlider to look like a thermometer
• Advanced skinning using Tweener, cursor position, color tweening, skin states, etc.
• Using the derive property
• Reusing compositions created in external MXML files
• Random art with Degrafa and Tweener
• Creating and using libraries

Visit the Degrafa Samples page and enjoy!

Here’s a general list of some of the changes and additions that were made between Degrafa Beta 1 and Beta 2:

Bugs

1. The collection base class has been updated with bug fixes it also now properly add(s)/remove(s) event listeners at the right moments. As this is the base class, these changes propagate up to all of it’s sub classed versions. The result is that adding or removing items to the collection through Action Script will now correctly dispatch the change and/or clean up.
2. Fill and stroke properties when directly set with a new fill or stroke will now properly update. This problem seen in Action Script, happens when you want to replace the fill or stroke objects on a geometry item with a different one.
3. On some of the geometry objects computation was being redone when a fill or stroke change occurred causing the object to be drawn twice. This is no longer the case.
4. On some geometry objects (path, polygon, and polyline), resetting the data property would not clear the existing items. Setting the data property will now properly clear and re compute the object.
5. The bounds and drawing commands in the Polygon and Polyline geometry objects were not correctly taking into account the x and y properties during computation. This will now work as expected.

ï¾ Enhancements

1. All Boolean properties accessible from mxml have be updated to show an enumeration of true,false. Makes the mxml experience more enjoyable.
2. We have added icons to all the mxml level objects so that the various objects are more apparent in the mxml outline view.
3. Drawing to arbitrary graphics contexts is now supported via the property graphicsTarget this property accepts an array of display objects and is supported on all subclasses of geometry. As part of this features functionality we also added the property autoClearGraphicsTarget. The default value is true and when true the target graphics contexts will be cleared before rendering.
4. The ability to nest geometry for proper composition is now possible. We also added a new geometry object GeometryComposition that makes a good root candidate for composing. This new object in conjunction with the graphicsTarget property allow one to use Degrafa with out having to setup a Surface and a GeometryGroup. However it is not a DisplayObject so with out a graphicsTarget specified no rendering will be performed.
5. The various color properties have been merged into one. We feel overall this will provide a much simpler method to specify the color settings as you see fit.
6. New state and stateEvent properties have been added to all geometry objects. At this time state is only taken into account when using the Degrafa skins and stateEvent is not yet implemented. The bright side is that we can now have all skin states in one mxml file. Expect more features to be added using these 2 properties in the near future.
7. Segments now have constructor arguments as well as a data argument. The data argument has been moved to the end of the argument list so you will have to update code that uses data in the constructor of a segment. The path object specifically takes advantage of this which allowed us to eliminate unnecessary parsing for each segment in the collection providing a performance boost.
8. LinearGradientFill and stroke now support a definable bounds via new properties (x, y, width, and height). If all of these or just width and height are specified then it will use the specified rectangle for it’s rendering. If none are specified it will fall back to the geometry object bounds or the rectangle that is passed to the draw method. We added the same support to the RadialGradientFill and stroke except the properties in this case are cx, cy, and radius.
9. Create objects reusing or overriding properties derived from other objects using the derive property.
10. New library base classes, starting with Polygon, others will soon follow as well as libraries to help get you started.
11. Specify ratios for gradients using different units, like inches, px, etc. using the ratioUnit property.
12. Some of the geometry drawing code has been updated. Circle, Ellipse, RegularRectangle, RoundedRectangle and RoundedRectangleComplex are no longer using the built in flash drawing commands (drawCircle()) for example. This was an important step for future enhancements. All drawing code now boils down to a command stack of moveTo, lineTo or curveTo. There will be refactoring throughout all geometry that will bring a cleaner code base and remove duplicate code once we have finished defining the architectural rendering pipline required to support where we need to go.

ï¾ 

While at 360|Flex there were a lot of questions regarding how Degrafa got started and whether or not we were “inspired” by MXML-G. I thought I’d (Juan) share a little of that information in case anyone else was wondering.

ï¾ 

About six months after I started ScaleNine I picked up on a blog post by Jason Hawryluk about a “Primitive Explorer” he had created that allows for programmatic drawing of shapes via set parameters. My initial interest in that blog post was exploring the potential for programmatic drawing for various purposes, but mainly skinning. Jason picked up on the link I had on ScaleNine to his blog and he sent me an email asking if I’d be interested in collaborating on the “next version” of the Primitive Explorer.

ï¾ 

Initially I just created a logo for the new Primitive Explorer (now the Degrafa logo), but as Jason and I carried on more conversations we realized that some of the things we were talking about lent themselves to more than an explorer and into a full framework. This framework would allow for programmatic graphics via MXML markup. The more we talked about it we started to realize that the framework could be capable of doing a lot of unique things, so we forged ahead with trying to pull it together.

ï¾ 

The process of getting the framework started was a collaborative one. I looked at things from a designer’s perspective and Jason from a developer’s. For the name of the framework, we decided on Degrafa, which is DEclarative GRaphics FrAmework compressed together. Plus, it was a short URL.

ï¾ 

As progress was being made, Jason made a comment on FlexCoders about graphics definable via MXML and it evolved into an email conversation with Ely Greenfield. That email conversation turned into an opportunity to show Ely and Glenn Ruehle what we were working on, as well as see what they had in the works. We had no prior knowledge that Adobe was working on something similar, so we were excited to share.

ï¾ 

Via an Adobe Connect session we got to see the first implementations of what Adobe was working on for graphics defined in MXML (later this became known as MXML-G). We were happy to see that Adobe had similar interests, but we weren’t sure how soon what they were working on would be available to the public, so we forged ahead.

ï¾ 

Adobe MAX 2007 rolled around and we got to see where Adobe was going with MXML-G. It was Thermo and Flex 4. Now we could see where things were going, but then we heard dates in 2009 for when some of the things we saw would be public. Again, we decided to forge ahead and in the process we were able to pick up other developers who saw potential in Degrafa. Guys like Ben Stucki, Pavan Podila, Andy McIntosh, Jim Cheng and others got involved, which helped push things forward.

ï¾ 

On January 1st, 2008, we released the first beta of Degrafa, dubbed “Origins”, and we were surprised by the response. People started using it for all types of things, like skinning, data visualization, product customizers, and more. Seeing this added fuel to the fire and since we’ve laid the initial groundwork for Degrafa we’re able to start doing some really interesting stuff. Everyone on the team likes to think that what we’re contributing to is something that may potentially change the way people think about graphics in Flex. Our hope is do offer up a lot of powerful features that are easily accessible and don’t sacrifice performance.

If you were at the Degrafa session at 360|Flex Atlanta, you already know this, but Degrafa Origin Beta 2 was officially unveiled. This release includes bug fixes, new features and performance improvements. These new additions were discussed during the presentation. So what’s included? Here’s a short rundown:

• Bug fixes and performance enhancements.
• Drawing can be directed to one or multiple DisplayObject’s that have a graphics object property and is no longer limited to Surface and GeometryGroup when using mxml. This is done through the graphicsTarget property which is a Degrafa collection of DisplayObject.
• You can also now compose geometry within geometry. For path, polygon and polyline, geometry is not the default property so you have to wrap the inner elements with a <geometry></geometry> tag.
• Specify ratios for gradients using different units, like inches, px, etc. using the ratioUnit property.
• Reuse compositions and shapes created in separate MXML files.
• Create objects reusing or overriding properties derived from other objects.
• Specify different color format types within one color property as opposed to separate properties. RGB, HEX, color key, CMYK all use this single property.
• Skinning with multiple skin states specified in one MXML file.
• New library base classes, starting with Polygon, others will soon follow as well as libraries to help get you started.
• And much more.

The documentation for these new features will be up shortly, as well as more samples and tutorials. In addition to this new release, we picked up a new team member, Sean Chatman, who created the Style Piece entry for the Degrafa Derby. He’ll be helping out with a number of things that I think will help people get up to speed more quickly with Degrafa and it’s capabilities. Sean will be doing things like creating tutorials, how-tos, and we’ll be expanding his “Degrafa Explorer” in a few different ways.ï¾ 

We got a lot of feedback at 360|Flex Atlanta and we’re taking that into account as we step back and evaluate the state of Degrafa right now before we begin to tackle the next version. A number of people had there own projects to show that had fully implemented Degrafa or extended upon it. Don’t forget, that if you’re using Degrafa, to please let us know so we can feature what you’ve done on the newly created Degrafa Showcase.

Some issues to keep in mind…

Source SVN access:

The source SVN is setup differently for beta 2. There will be 3 places you can get at the Degrafa code base:

Beta 1:

We have moved this to a new tag so that folks using it, can continue to do so with little trouble. The new location is “http://degrafa.googlecode.com/svn/tags/Origin Beta 1/ Degrafa” as opposed to “http://degrafa.googlecode.com/svn/trunk/Degrafa”. If you wish to continue using the beta 1 version please update accordingly.

Beta 2:

The Degrafa beta 2 can be found at “svn/trunk/Degrafa”. With this version we will now be reactive as opposed to proactive with regards to bug fixes. No new features will be added and this can be considered a fairly safe zone to hook into. If you don’t plan to upgrade in the future, this release can also be found at “svn/tags/Origin Beta 2/Degrafa”.

Development:

The Degrafa live development branch will be made available so that you can get the new features as they become available. This allows you to see/use the most up to date code base, get your hands dirty, provide valued feed back etc. All Degrafa development will now work off this branch. Everything from experiments to prototypes to subtle changes.

Warning: This is a moving target. As we are still in beta this will be the most volatile svn access choice. However, the benefit is that you’ll be able to help us pave the way and mold Degrafa to your needs by providing input in real time. Of course nothing is stopping you from using one of the betas and being up to date with the new advancements at the same time.

This will be available soon and we will announce when it becomes available.

We feel that the transition vs reward from beta 1 to beta 2 is worth the effort; but we also realize that some organizations are using beta 1 for real products. This is to be weighed based on your judgment. The Degrafa team is always available to answer any questions, so feel free to integrate us into your decision process.

We are working on a Beta 1 – Beta 2 change log, which will be available soon as a wiki page on Google Code.

SWC files:

Refer to the downloads section for the file you wish to use. The beta 2 marked files will be updated as critical bugs are identified. Beta 1 files will remain unchanged.ï¾  If you downloaded a beta 2 SWC prior to this blog post date you should download the SWC again as there have been some other bug fixes.