Line drawing in Flash is, on the whole, pretty darned fantastic. You get curves, lines, varying stroke widths and colours etc. all nicely anti-aliased with just a few commands thrown at the API. However, when it comes to pure quality and flexibility it has quite a few short comings, which is especially a problem when it comes to drawing interesting, varied, magical lines.

Here’s a few (to get the ball rolling) limitations with line drawing in the Flash drawing API.

1. Fractional stroke widths aren’t supported

Want a stroke width 0.234 points / pixels wide? Bad luck champ!

2. Anti-aliasing could be better

I have no references (anyone?) to the type of anti-aliasing that Flash does, perhaps as a guess it looks like some kind of an A-Buffer or just a basic super sampling algorithm, but whatever it is it could be a whole lot smoother.

3. Dotted lines aren’t supported in code

Easy to hack for straight lines but quite a bit harder for curved lines

4. Gradients on lines don’t follow curves

5. You can’t change stroke widths, colours, alpha etc. values smoothly along the length of a line

6. Brush strokes, texturing, sampling etc. aren’t supported

7. Line “edges” are always perfect and parallel

Thankfully all of this can be worked around with code (ahh, beautiful, powerful code) which I am going to go through in series to build up some really powerful line drawing code that a lot of nice effects can be achieved with.

If there are any things that you want covered or have seen done (journal article references are also good!) please let me know so that I can have a go at incorporating into this series.

Over the years there has been a number of work arounds / solutions. The following is a run down:

1. Print via a vector file.

This can be accompilshed using a postscript printer driver (back in ye olde days) or by just using Acrobat via print in the context  menu (PC only I believe?). Joshua Davis was one off the first to output images via this method. On the bright side this gives you vector output that you can scale up to whatever size you like. On the downside you don’t get gradients, transparency or effects and since it is vector it can be unwieldy or un-preocessable when you have a few hundred thousand or million vectors (!).

2. Print the screen to tiles

This is horrid but it works. Basically hit “zoom in” via the Flash context menu on a published SWF then take screenshots to create tiles. Stitch together in your favourite image editor. Ouch.

3. Output to bitmap tiles directly

The idea with this is to scale up the containing MovieClip and draw it across a grid of images that cover the output image that is the size that you want. As you are rendering to bitmap you can do all sorts of nice things like gradients, multipasses, transparency etc. The main problem with this is that you get a lot of tiled bitmaps to deal with. The easiest way to deal with the tiled images is to use something like Image Magick and automatically create a script file that stitches it all together - one click to stitch. If you want you can also delete the intermediate images via a script. If Air let you call an external program you could save yourself a click (alternatively you could just bundle up a Flash app in something like Zinc and that let’s you call an external program). The size of the tiles can either be a maximum of 2,880 x 2,880 if you are going out from Flash or a maximum of 8,192 x 8,192 if you are using ImageSnapshot in Flex.

4. Output to bitmap tiles using a single virtual canvas

This is the same as 3, however you do it via a nice class inbetween to treat the tiles as one big fat canvas, or rather one BigAssCanvas. To get this to work you will need to allocate memory for all the tiles before you do anything with them. This can be a limiting factor and if the output image is too large it won’t work.

5. Output to a single bitmap via external image hackery

This is mentioned in the comments for BigAssCanvas and is apparently what Erik Natzke is (was?) doing. The trick involves loading in an image of the dimensions that you wish the output to be, and then you write to the BitmapData of that image before saving. This has the same issue as 4 in that you will be limited by the amount of RAM that you have. Another issue is that you have to create a target image file before you start so it won’t work if you need to dynamically set the dimensions of the output file. Also check out BitmapDataUnlimited for another implementation that works along these lines.

One question is what about bitmap effects? Well I need to test this further! In my initial test I got drop shadows and glow working quite well when I used small tile sizes. I expected there to be artificats when an object got clipped but it seems the Flash renderer is smart enough to work out the bounding box for the effect and clip that (there is a built-in function which does just that!). I guess that there is probably a maximum size for the effect bounding box before the effect will refuse to render but I need to confirm this. I did note that lots of effects on top of each other in the same MovieClip slows rendering down a lot and sometimes kills Flash. You can get around this by layering effects in separate MovieClips or you can just compute the effects yourself!

Personally, if the image isn’t truly massive (i.e. it fits in RAM), I go with option 4 and if it is truly massive then I head for option 3. To get option 3 to work without allocating a lot of memory you need to make sure that you can render your artwork multiple times. i.e. that it is repeatable. Another thing to notice is that you then have to render the artwork as many times as there are tiles. So if it takes a few minutes or more to render the artwork you could potentially be waiting hours or days.

If you are doing something a bit smaller but still greater than 2880 x 2880 you could try something like SWFShot.