It was obvious that I had to write a few more lines about Zinc in the near future, but somehow this topic didn’t leave me alone at all, and no, I’m not writing about Zinc because I like it, I’m writing this because I don’t want that other people fall into the traps I fell while using it. Do I like Zinc? Yes & No, it’s a very weird situation, it’s useful, it would be even more useful if they would do their job right, but I already wrote about it here. So let’s leave this discussion out of here.
So let’s begin from the ground up, your goal is to resize and save the newly resized files back again into a jpeg. Sounds easy?
It should be but it isn’t!!
First of all I have to tell you that I began my project with Zinc 3.0 which supports bytearrays, it was really cool to work with it, as I was able to use the JPEGEncoder class that anyway writes bytearrays.
Let’s look at the methods available:
setData();
writeData();
setDataBA();
writeDataBA();
You would achieve our goal somehow like this:
var bmp:Bitmap = DisplayToBitmap.draw(bSprite, false); var bmd:BitmapData = new BitmapData(bmp.width, bmp.height); bmd.draw(bmp); var jpgEnc:JPGEncoder = new JPGEncoder(85); var jpgStream:ByteArray = jpgEnc.encode(bmd); var jpgPath:String = persFolder + "\\My Pictures\\myScreensaverThumbs\\" + _arrayCCopy[i]; _convertedArray.push(jpgPath); mdm.FileSystem.BinaryFile.setDataBA(jpgStream); mdm.FileSystem.BinaryFile.writeDataBA(jpgPath);
But since I had to use Zinc 2.5 because of performance problems with the application, guess what? You don’t have the possibility to write a bytearray down to the harrdisk with the writeDataBA() method. So how the heck are you going to write a jpeg?
Let’s look at the methods available:
setData();
writeData();
Yeh, it’s not much, and yeh it didn’t change a lot in Zinc 3.0 besides that you can write Bytearrays.
So what you have to do is basicall write HEX code or Pipe ( | ) delimited strings, do that on a few dozen images and you can go get a cup of coffee and when you back it might be done by then.
var bmp:Bitmap = DisplayToBitmap.draw(sp, true); var pngBA:ByteArray = PNGEncoder.encode(bmp.bitmapData); MonsterDebugger.trace(this, pngBA); var dataString:String = ""; for(var i:uint=0; i < pngBA.length; i++){ if(i>0) { dataString += "|"; } dataString += pngBA[i]; } mdm.FileSystem.BinaryFile.setData(dataString); mdm.FileSystem.BinaryFile.writeData(persFolder + "\\My Pictures\\myScreensaverThumbs\\" + _arrayCCopy[v]);
Now that you know how to to handle this, let’s think about a few methods that Zinc 2.5 API provides you with:
bmpToJpg();
Nice little function but it only works if you have .bmp’s on your harddrive, who uses .bmp’s nowadays?
jpgToBmp();
hmm.. sounds better, you can grab a jpeg and convert it to a .bmp file, after that you can use the bmpToJpg() method to save them back, but come on, does that really make sense? After all you are using 2 methods to do a simple conversion and resave.
deleteFile();
Believe me or not, actually it’s quite obvious, you converted a jpeg to bmp and the bmp to jpeg, now you have
1) an original file
2) a bitmap file
3) a converted file
Isn’t that one too much?
Yep, now you have to use the deletefile() method to delete the bmp file which you are definately not going to use.
Now you used 3 methods to accomplish a simple task, that can be done in pure as3 with less lines of code. Now you ask yourself “Tiago you are talking about Zinc 2.5, that’s anyway outdated” have a look at the methods available for Zinc 3.0. As you see they don’t have a simple “read jpeg / save jpeg” method. WHY NOT?????
But let’s continue, by now you know how to resize and resave images with Zinc 2.5 and Zinc 3.0, but you are probably not only going to convert one single image on the fly, that would be kind of boring no?
Let’s try to get a list of files from a specific directory, to accomplish that we need the getFileList() method, below a simple line on how to use it
var myFiles:Array = mdm.FileSystem.getFileList("c:\\my images\\", "*.jpg");
Sounds simple, you build an array and call the getFileList method pointing to the location you wish and filtering it based on the file ending, at the end you don’t want to get some weird errors because you try to convert a .doc or whatsoever into a .bmp / .jpg
if you don’t believe me, then try this out on your own doesn’t matter which version of Zinc you own
- Create a folder on your c drive (it’s easier to target then anything else)
- Drop a few images and rename the filetype of some of the files to .JPEG, .jpg, .jpeg (case sensitive)
- Run the code above in your project using the path to the folder you just created
Result:
Only the files with the case sensitive .jpg will be pushed into the array, yeh now you know it, this damn thing is case sensitive, so let’s create some more arrays to handle the different filetypes and use some more processing time and memory then needed, the same goes for every filetype you want to push in. In my case I had to get all images with a filetype of (.jpg, .jpeg, .JPG, .JPEG, .bmp, .BMP, .png, .PNG) 8 querys on the filesystem all using the same method, sigh..
Have you ever ran into a Zinc problem before, let us hear your experience with it.

The Zinc – Saving images by Tiago's Weblog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 2.5 Switzerland License.




I’ll ask you this since you’ve dabbled with 3.0 and I never touched it (2.5 ex-user here): In your professional opinion, is there even a reason for 3.0 to *exist?* When support for 2.5 went the way of Alderon then 3.0 emerged months later, I was like “WTF?” I looked at the API and didn’t see anything new or compelling.
I’m not talking about MDM’s support or the fact that they locked the 2.5 forums. Just software-wise… should 3.0 have been born?
Hi Dunlavy, absolutely not, there is NO reason Zinc 3.0 to exist, I switched back and forth during development without having any issues (besides the one with the bytearray). So just because of enabling bytearrays and a new GUI, there is absolutely no reason to switch to Zinc 3.0.
Hello. Have you ever tryed to download video files and save in the file system using zinc? I tested here with images and it worked fine for me, but with videos its so slow that the flash crashes. I’m using the writeDataBA. I dont know if I understand right what you sayd but is the writeData faster than the writeDataBA?
Diego, the writeDataBA is actually supposed to be faster as it’s a native call from flash writing bytearrays, that it becomes slower with videos, is in my opinion not the problem of flash rather then ZINC, videos are normally bigger then images and therefore it needs a bit more time & resources to save but it shouldn’t crash flash at all.
I wouldn’t even think about using ZINC to save a video or anything else in the future, have a look at my previous ZINC post, the guys from NorthCode have an offer running for ZINC users that you might like