Honestly, my recent project has been getting more and more boring. The core work is basically done, and what’s left is almost all grunt work — nothing new or fun. Yesterday I finished The Settlers 7 and was just about to drift off to sleep, when I suddenly came across two pages that jolted me wide awake: http://www.buraks.com/azoth/ and http://philippe.elsass.me/2010/05/as3-fast-memory-access-without-alchemy/ , and just like that I was energized.
Reading and writing ByteArrays in FlashPlayer always falls short when you’re up against certain extreme requirements. These past couple of days Xu Can got pushed into hunting for some unorthodox, unofficial workaround — and sure enough, he actually found one. I’d heard before that haXe is so fast because its author found the low-level interface FlashPlayer 10 provides for Alchemy, but for various reasons I never used haXe. Seeing these two pages showed me some new tricks — turns out the three of them are goods from the same circle. All three found the “back door” FlashPlayer 10 opened for Alchemy to squeeze out performance at a low level.
Now that I’ve seen something new, it’d be a shame not to play around with it. I still don’t plan to use haXe — I want to depend on unofficial APIs as little as possible. Apparat is great and powerful, but it needs a runtime installed, and it’s a framework with tons of features; I don’t like using something where more than half the features go unused.
Azoth is a small tool built specifically to give you a high-speed memory access API — compact, lightweight, single-purpose. That’s exactly the kind I like. It lets us use a ByteArray as a standalone block of memory. Download http://www.buraks.com/azoth/azoth104.zip, then use the fastmem class it provides to read and write data. Once you’ve written your code and compiled it to a SWF, run azoth.exe to inject it into the swf, and it becomes the optimized version. Without the injection, it’s obviously slower than the APIs Flash provides.
Since I’m playing around anyway, I figured I’d go looking for trouble and run an experiment. Spurred on by Xu Can, I had a momentary burst of foolish enthusiasm today and tried using this high-speed memory access to optimize bitmap rendering. The basic idea: store all the BitmapData used for rendering as binary inside a single ByteArray, with each bitmap having a start memory address and a length; manually manage all the internal addresses of that ByteArray and maintain the image layering; in the end, the only thing output to the view is a single BitmapData — all in hopes that fast reads and writes would bring a performance boost.
After trying it, the results weren’t impressive — even though memory reads and writes are faster, it moves the burden of implementing copypixel onto per-pixel processing. Copying a mere 300*300 image to another image requires computing 90000 * 2 memory addresses; bigger images mean even more address computation, and doing all that math at a high level is very time-consuming. And copypixel between images isn’t just plain value reads and writes — it also has to blend based on alpha, and the color math eats up more time. Flash’s own bitmapData copypixel takes only 4ms to process a 300*300 image 5 times, whereas running 180000 looped additions in Flash takes 7ms on my machine. So there you have it: throughput isn’t the problem — the amount of computation blows up. High-speed memory access isn’t meant for this kind of thing. I really was having a moment of foolish enthusiasm.