We’ve been linked to by a fellow agency called Airtight Interactive on the subject of altering cross-domain bitmap data in Flash. They mention the server-side proxy work-around that i’ve used, calling it “prohibitive” for large-scale apps. That was the concern i raised when a casual games publisher approached me to ditribute Jigsaw! across its extremely high-traffic game portals.
Untold Entertainment’s advantage is that we do not bear the bandwidth costs that the jigsaw game’s Custom image feature may bring down like so much Biblical wrath. There are ways to mitigate the cost, which i’ll discuss after posting the solution.
(Click to read about Adobe’s rationale for preventing cross-domain image manipulation in Flash.)
Images loaded into a Flash swf from another domain (ie www.notMyOwnSite.com), won’t respond to BitmapData methods like draw().
Flash needs to see that the image comes from your own domain. To pull this off, you set up a server-side script and pass the image url to it. The script loads the image to your domain, and returns that image to Flash. Since the image comes from your domain now, you can mess around with it all you like.
The script i use is written in PHP. Here it is, at its most basic:
1 2 3 4 5 6 7 8
<?php $mimetype = $_GET['mimetype']; $file = $_GET['file']; header("Content-Type: $mimetype"); readfile($file); ?>
There are some clear problems with this approach:
1. Since your server has to load the image, you carry the bandwidth cost for trafficking that image. i consider this the cost of doing business. If you want to offer a cool feature like custom player-created jigsaw puzzles, you have to pony up the cash.
And then, logically:
2. Some malicious user could set up a script to repeatedly pass enormous images through your server every second of every day, putting you in the poorhouse, or forcing your provider to shut your site down. This is best handled by adding limits to the script. Prevent users from loading images above a certain filesize, and limit the number of script calls per user.