I recently added a good chunk of fresh code to Degrafa ahead of the 3.2 swc release (later this week). The bulk of that code was for something called VideoFill.

This post is a quick introduction to VideoFill. Over the coming days I'm going to blog some of the specifics about how to use VideoFill as a series - as a starter for people to do their own things with it. Can't wait to see what people use it for....

I'm sure most people reading this would prefer to get to the samples etc, but I'm going to take one post to meander a bit through a brief history (check back tomorrow for the start of the good stuff):

VideoFill actually had its roots in an IM conversation I had with Juan Sanchez after getting VectorFill into Degrafa last year. It went something like this:

Greg: "Right that's VectorFill done, what's next?"

Juan: "VideoFill ? xaml has it, we should too!"

Greg: "Yeah right, very funny!"

Well ok, it probably wasn't exactly like that, but that's the way I kind of remember thinking about it afterwards!

The reason I set the challenge aside mentally at the start as a joke was not that I considered it was impossible to do - but that I immediately considered the 'obvious' way I had thought of doing it (as native masking and rendering to bitmapData and redrawing for each video frame update) would be a performance killer - which it would be. But I did keep the goal in mind and always wanted to make it happen after that conversation. A couple of months later I figured out the way it could be done because I discovered that it was possible to update the appearance of something drawn by the flash drawing api without redrawing it each time- by changing the bitmapData that was used in a bitmapfill - the flash renderer does the rest**. I knew this was possible with the native Bitmap class, but hadn't made the leap to using the technique in the drawing api. Based on this I'm guessing that the native Bitmap DisplayObject is not much more than something between a Shape and a Sprite with a drawRect internally in the way its implemented inside the player as it seems to behave the same way. Anyhow, that was the ahah! moment when I was pretty certain I could do a form of VideoFill that was going to be performant to a degree that makes it usable in Degrafa.

So at a basic level, the way VideoFill works is to leverage as much as possible the native flash player renderer's automatic visual updating of what is rendered based on updating the referenced BitmapData used in bitmapfills. You update the BitmapData from the video content and it updates what you see. Simple - at least in concept! This works well for most uses, but is not suitable if a filter or any form of bitmap cacheing is applied on or above the object where a VideoFill is used in the Degrafa Object 'tree' or in the target displayobject's displayobject tree (and this also applies with the Bitmap DisplayObject). There is a setting on one of the classes I've added to make things work in this situation, but it's more CPU intensive simply because it requires a full redraw of the relevant degrafa composition each video frame update.

Going from concept to reality was a bit longer than expected though - mainly in terms of finding the time to code and test this. I had the idea sitting there for a number of months, and after prompting by Jason Hawryluk in March this year actually coded a working proof of concept over a single weekend - using the Wolverine trailer as my test clip - and it served pretty well for the early sneak previews. But it wasn't 'til I had a break in my work calendar recently that I was able to knuckle down and punch out the real code. And I started with an end goal in mind: I wanted to get to a point -in terms of ease of use- where I could animate playing video 'puzzle' pieces together to form the regular video as a rectangle. I was able to do that recently in about 10-15 minutes more time than it takes to draw the puzzle pieces in Illustrator or Inkscape (which for me is quite slow!)... so you will see that soon, during this blog series!

SO WHY DO IT?
As to why I worked on VideoFill....well that kind of has two main facets to it.

The first one is simply because I thought it would be a cool thing to do. Initial reactions to the sample by others seem to indicate at least a few other people think so too!

The second reason also stems back to Juan's original comment... one of the things I have focused on with my contributions to Degrafa is feature parity with other graphics markups*. Most of that effort has centered on features that match or extend what's available in SVG. Of course flash and flex have video support and many player classes that function at the DisplayObject level. Video support in SVG is coming in SVG 1.2 and also in html 5 and I knew in the background that it was already there in XAML although I didn't check it out at any point as I was working on VideoFill. In fact, I only just recently looked at XAML's videobrush documentation for the first time....and, well,  I believe we have an easier to use implementation with VideoFill, with more features :). But I guess I'm a little biased as well.

So....the next post in this series will cover a feature overview of VideoFill and VideoStream (the supporting player class) and after that I'll follow up with some samples of controls and various effects.

By the way - I had a conversation with Juan yesterday that went something along the lines of:

Greg: "I should really get to blogging this stuff. Maybe I'll start with where it all came from....not sure about that though."

Juan :"If you blog it I'll read it. I'd find it interesting." ***

Hmmm, I wonder what Juan's IP address is.....

Tomorrow I'll give a run down of VideoFill features. And a shorter blog post. I promise.

*in terms of feature scope the breadth of Degrafa already far exceeds most other graphics languages, by feature parity I mean the ability to fully express something that is possible in other languages for comparable features.

**earlier this year (2009) I helped someone out using this same technique in flash timeline based code in the adobe as3 forums here

***Geez I hope he doesn't mind me talking about him on my blog. What am I worried about?- he won't read it!