Does the type of image matter when you’re compressing it to PNG? Does it affect performance? Size? This week’s article looks into these questions to find out how each of the PNG compressors performs on three different types of images: an icon, a photo, and random noise.
Posts Tagged performance
Flash Player has had built-in PNG compression since version 11.3. But how does it fare against all of the other PNG compressors out there? Does it compress faster? Does it produce smaller file sizes? Today’s article explores your options when it comes to compressing PNG files so you can get the fastest or smallest PNG possible.
Which image format is fastest to load? That was perhaps the most relevant question in last week’s article, so it’s time to explore it more deeply. Today’s article examines differences between different types of PNG, JPEG, and JPEG-XR files to answer questions like “does the JPEG quality setting matter?” and “is indexed PNG faster than full (ARGB) PNG?” Read on for the test and all the details.
Are you using the fastest assets you can? Yes, even the file format of the assets you use has a big bearing on the performance of your app. Ask yourself: is PNG faster to decompress than JPEG? Is it faster to compress to JPEG-XR or PNG? Do the quality settings matter? Today’s article explores the performance of Flash’s main three image formats—PNG, JPEG, and JPEG-XR—to find out which decompresses fastest at load time and compresses fastest at save time.
As I discovered in the previous articles, loaded bitmaps are stored in memory in two forms: the compressed PNG, JPEG, JPEG-XR, GIF file and the uncompressed RGBA pixels. If you don’t use the pixels, Flash Player will reclaim its memory and then uncompress it if you use the bitmap later on. However, if you do plan to use the bitmap, isn’t the compressed file data just memory overhead? Today’s article will show you how to dump this unused file data and save a bunch of memory.
It came to my attention in the comments of Preloading Bitmap Decompression that Flash Player would actually free the decompressed bitmap memory if you didn’t make active use of it, similar to garbage collection. So if you followed my strategy from that article to preload a bitmap, it may have been un-preloaded for you by Flash Player! Today’s article shows you how to work around this little problem.
Spriter is a tool for creating sprite animations out of multiple images. By moving, rotating, and scaling them over a timeline you can create much more efficient 2D animations than traditional full-frame animation. While Flash animation has worked similarly for years, it’s largely incompatible with the Stage3D API that is quickly becoming mandatory to achieve adequate performance. Today’s article will show you how to use Spriter in your Stage3D-powered Flash app via a Starling and some custom classes I’ve created.
Since they were introduced way back in Flash Player 8, bitmaps have become a core feature in almost all Flash apps. The way you handle them—creation, operations, and destroying—is one of the most important factors determining your app’s performance. Today’s article shows one little-known trick to help out the performance of loading and using bitmaps.
Today’s article is about three totally unrelated discoveries I’ve recently made in AS3. These answer three questions I’ve recently had. Should you cache the object you’re looping over with a for-each loop as a local variable? Can you clear a Dictionary or Object with a for-in loop? Is it faster to write your own version of Vector.indexOf? All of these questions are answered in today’s article!
Stanford’s Sean Eron Anderson has a great page titled Bit Twiddling Hacks. This is a great resource for C programmers looking to employ bitwise operators (& | ^ ~ << <<< >> >>> etc.) to speed up their code. But what about AS3 programmers? We have bitwise operators too, but will the same tricks work for us? Today’s article ports some of these bit twiddling hacks to AS3 and tests to see if any ground is gained.