Greg Dove, a Degrafa core team member, and the creator of Degrafa’s VectorFill, has broken new ground with another new Degrafa paint object, VideoFill.

There have been a couple of sneak previews of VideoFill over the past few months; Juan showed a quick preview at 360|Flex earlier this year and Greg showed a quick demo at FlashCamp in New Zealand as recently as September. Well, no more ’sneaks’ (apart from this one!), it’s finally going to be available from beta 3.2.

You won’t believe all the things you can do with this, suffice to say that it makes some video effects that could be difficult to achieve – even in the Flash authoring tool – very easy to code in Flex with Degrafa.

To be honest, we don’t know what you will do with VideoFill. We can see it being used in creating custom players for specific video content or for specific vector/clipping effects for video -this is quite practical and quick to do with VideoFill. And yes…it can be used for skinning if absolutely required (’absolutely’? yeah we can’t think of when that would be either….but hey, we’ll let someone else tell you not to do it!).

A screen capture from the Avatar trailer being used as a VideoFill

Under the hood, to make VideoFill work, a complete new custom video player class was written from the ground up, designed for the purpose of supporting the way that VideoFill does its magic internally within Degrafa. VideoFill does require data access permission to work with the bitmapData of the video, but that is quite straightforward if you load from a domain under your control. It handles both progressive download video and also has support for rtmp streaming video content. Greg is also planning to add in support for the Camera object to round things out in terms of capabilities/support so that it’s easy to add live webcam content as a fill.

Back in the realm of regular paint classes in Degrafa, VideoFill is an ITransformablePaint object, which means you can spin, skew, scale and move a VideoFilll inside its target Geometry object using Degrafa’s Transforms…all while the video is happily playing! Watch out for more VideoFill information and tutorials after additional exciting beta 3.2 announcements in the coming days. We’ll add an official VideoFill sample to the Degrafa samples page as soon as beta 3.2 is released…for now you can whet your appetite on this one.

In Degrafa Beta 3 we introduced a new text object called RasterText. This object allows you to add text to your graphics compositions just like any other geometry. You can also have multiple text objects inside something that normally allows for one. For example, you could use RasterText to create 2 text items in a Button skin, rather than relying on the default single label of a Button, kinda like the example below. Click here to view the source.

RasterText is like other Degrafa geometry objects in the way it can be composed using fills, transforms, etc. RasterText renders as bitmap data, so things like Decorators and strokes around letters won’t work because there is not path defined. That’s what VectorText will take care of in the future.

Below is an example of several Degrafa fill types being applied to RasterText objects. As you can see, you’ll no longer be limited to solid-colored text. Click here to view the source

The ability to add these kinds of fills will be coming soon in Degrafa Beta 3.1 along with some other really great updates. Now that the core feature set is defined we’ll be looking to push out smaller updates more regularly. In the meantime you can still do some neat stuff just composing RasterText object together, like the CS4 Icon Previewer below. Click here to view the source

The focus of Degrafa beta 1 and 2 was to set up a solid core that would allow us to do really innovative things and make really complex things easy to do. We’re also chipping away at the need to have any external graphics referenced in your project. A new feature in Degrafa Beta 3 gets us even closer to meeting these goals.

This new feature is a new Fill type called VectorFill that is going to change the way you think about what’s possible visually in your applications. VectorFill allows you to compose any Degrafa geometry together and use it as a Fill for any other Degrafa geometry. As a simple example, imagine you wanted a background of diagonal lines. To achieve this with VectorFill all you need to do is draw one diagonal line using Degrafa, specify that Line as a source in a VectorFill, then apply that VectorFill to a Degrafa geometry object using the fill property.

Just like any other Degrafa object, you could edit that diagonal line, say change a color, and that change will dynamically get updated in the applied VectorFill. Also, when we say you can compose any Degrafa geometry together we mean shapes, transforms, fills, repeaters, strokes, and so on. You could move shapes with in VectorFill to create panning or use VectorFill with the Flex charting components to make really rich visuals. The possibilities are endless.

We’ve also added additional properties to VectorFill to allow for even more powerful ease of use. You get all the BitmapFill goodness of repeat, scale and angle etc. You also get the recently revealed fill transform features as well. And you also get filters, autosettings, background SolidFill and the ability to clip the fill source geometry based on a third geometry object (or even part of composition). Let’s take a look at some samples.

Below is an example of a VectorFill being used in a Circle. As you move your cursor over the eagle a zoomed view is shown. If you use your mouse wheel you can zoom in and out. This is not a mask, but a VectorFill with a clipSource setting (assigned to the magnifier’s lens) moving around and scaling in the Circle. To show a possible use, a second fill, a BitmapFill is used to take ’snapshots’.

Another example is using VectorFill to customize charting components. The example below uses a VectorFill to represent visually the sport for which the data pertains to. This opens a lot of doors for really custom-looking data visualization using existing charting components.

A more simple example is based on the scenario I outlined above; a diagonal line background. Most examples I’ve seen that use Degrafa always have one bitmap graphic in there for some kind of background. Well, now you can go completely vector. Below is a diagonal line background that uses a VectorFill and a Degrafa Line applied to a Rectangle. I’ve thrown in some other controls so you can see the live updates on the VectorFill.

We’re really excited about what will now be possible with this new VectorFill and some of the other new features we’ll be sharing soon.

One of the most influencing factors behind the new features we add to Degrafa comes from the community. As Degrafa has progressed we make sure to follow the Degrafa Group as much as possible to help guide people on how to use it and answer questions.

In some cases it’s hard to help because the version in question just doesn’t support what the person is asking about. When these scenarios come up we take notes and add it to our “to do” list to see if we can provide a solution in a way that elegantly fits into the roadmap for Degrafa.

One scenario that came up was the ability to load a bitmap from an external URL to be used in a Degrafa Fill. Currently you have to embed a bitmap to use it in a fill. However, Degrafa Beta 3 will allow to specify any external bitmap source to be used in a Fill. This will be no real effort to achieve this if loading images from the same domain as your application, but you’ll also be able to use images from an external domain that provides a permissive crossdomain.xml file, like Flickr.

Another recent addition to the existing COLOURlovers API, was support for runtime ‘pattern’ loading via crossdomain permissions, from COLOURlovers.com. The way we’re implementing this makes it pretty easy for users to take advantage of.

Below is a simple example using the ColourLovers API and runtime loaded random ‘patterns’ used as BitmapFills. That’s to give you an idea of what’s possible. After that a quick explanation of how easy it will be to use runtime loaded images in your BitmapFills.

View Sample

Loading BitmapFill images from your own domain

If you are loading images from the same domain as your Flex application, no access permissions are needed, and using a runtime loaded BitmapFill is very easy*.

If you have your images in an images directory within the same directory as your main application swf, then you would normally specify the source as follows:

1
2
3
4

<bitmapFill
      id="localExternalBitmapFill"
      source="images/myImage.png"
      angle="45" />

That’s basically all there is to it! When the image has loaded the fill will appear, for the Geometry item(s) that use(s) it. The additional delay is an indeterminate time after your Flex application has initialized, simply because your image is not embedded and it takes a little time to load. If you use the same source url assigned to multiple BitmapFills (you may for example use the same external image, but have different settings applied in another BitmapFill), then the external image file is only loaded once, and only one set of BitmapData is generated for all the BitmapFills that use it.

Loading BitmapFill images from External Domains

These examples relate to using a Flickr source:

a) A simple, one-off example:

1
2
3
4
5

<bitmapFill
      id="bitmapFill"
      source="http://static.flickr.com/15/88928122_0f06ac7417.jpg"
      rotation="45"
      smooth="true" />

The above works as is, because flickr has the crossdomain permission policy file in the default location expected by the flash player at http://static.flickr.com/crossdomain.xml. This example can be expressed in another way as a separation of basePath and relative url as in the following example.

b) Loading multiple images from a single external location, managed with a LoadingLocation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<utilities:LoadingLocation
      id="flickr"
      basePath="http://static.flickr.com/"
      policyFile="http://static.flickr.com/crossdomain.xml" />
<paint:BitmapFill
      id="bitmapFill"
      loadingLocation="{flickr}"
      source="15/88928122_0f06ac7417.jpg"
      rotation="45"
      smooth="true" />
<paint:BitmapFill
      id="bitmapFill2"
      loadingLocation="{flickr}"
      source="142/325447236_ac4c1b9b3a.jpg"
      rotation="30"
      smooth="true" />

The above is likely to be suited to applications which have collections of external assets hosted externally, and where the location of the assets (domain) may change at some point in time. By setting up a single LoadingLocation to reference a basePath and policyFile (particularly if the policy file granting access is not using the default name and/or in the default location) you can make code maintenance easier if/when the external location of the assets changes.

As you can see the use of external images from within mxml is quick and easy. Watch out for more additions in the Degrafa Fills arena coming up before too long in another beta3 preview post.

*However you should also be aware that if your domain is accessed with both http://www.mydomain.com and http://mydomain.com then you may still need a crossdomain.xml file that grants permission to both, if you specify absolute urls for the local domain image files. The reason for this is that if you specify a url for the image that is on a different subdomain than that under which the application swf has been accessed, flash player security rules come into play and the flash player will seek permission via a policy file – which will fail to be granted it doesn’t exist. You should be ok using relative urls.

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?

As Degrafa evolves, Jason and I are trying to make sure we can account for a number of features someone may find important when creating graphics with the framework. Fills and Strokes are very important because they literally make up the shapes that get drawn.

Without a strong solution for those two things you’re left with a something somewhat lackluster. Here’s an example of where things are at so far with Fills and Strokes:

Fills

Fills are created outside and independent of any shape to make sure they can be repurposed. Each type of fill is declared in between a tag, so the MXML for all these fills together would look like this:

Bitmap Fills

Let’s take a look at each Fill separately. The top-left circle is an example of using a Bitmap Fill and the Fill is created like this:

The imageSource variable name points to an embedded image, repeat allows you to specify if you’d like the image to repeat, rotation allows you to rotate the bitmap fill and smooth allows you to smooth out the bitmap fill. Smooth was helpful in this example where without it the edges of the repeated image were jagged.

Gradient Fills

Gradient fills allow you to create linear and radial gradient fills with multiple color, alpha, and ratio specifications. The top-middle circle is an example of a Gradient Fill. The MXML looks like this:

This creates a 3 color gradient fill with various ratios and alphas.

Solid Fills

Solid fills are pretty straight forward, it supports color and alpha. The MXML looks like this:

Working with Strokes

Just like Fills, Strokes are specified independent from any shape or object. Gradient Strokes, both linear and radial, and Solid Strokes are part of Degrafa. You can also specify things like joints, caps, spreadMethod, angle, miterLimit, scaleMode, pixelHinting and more. The MXML for a group of Strokes would look like this:

As things progress, the ability to created different stroke styles like dashed, dotted, random, etc. will be added as well as the ability to add start/end caps like arrow heads, shapes, images, etc. Here’s an example of some strokes:

Gradient Strokes

As mentioned above, Radial and Linear Gradient strokes can be created using Degrafa. The code for the top-left example looks like this:

The MXML for the radial stroke example to the top-right has square caps and bevel joints and looks like this:

Solid Strokes

Solid Strokes can have caps, joints, color, miterLimit, scaleMode, pixelHinting, etc. specified. The MXML:

Another thing worth mentioning is that we’re looking to allow the ability to specify Fills and Strokes properties through CSS, so there’s a way to maintain consistency throughout an app without code redundancy.