結果は by.blooddy.crypto.image.PNG24Encoder が圧倒的に最速！！ エントリ内からのリンクが切れてるので、使ってみたい方は BlooDHounD’s workspace の blooddy_crypto.swc からダウンロードして下さい。

透明・不透明共に速い速い！Alchemy 使ってるのか気になるところです。

PDF を FlashPlayer 内で作成する為のライブラリです。 Java の iText ライブラリを AS3 移植とのことです。 チャプタ・セクション・パラグラフ・フレーズ・イメージなどの基本要素と、カラム・リスト・テーブル・セルなどのレイアウト要素を用い自由にレイアウトした PDF を作成することができます。 また、 AS の GraphicsAPI のようなベクターグラフィックスやグラデーション塗りにも対応した多機能なライブラリです。

purePDF についての情報は下記リンクをご覧下さい。

• purePDF, a complete actionscript PDF library - sephiroth.it - flash world
• purepdf - Project Hosting on Google Code
• purepdfを使って日本語フォントを指定したpdfを作る - nod::ぶろぐ:RIA::Flex/AIR/Flash

問題点

日本語などの 2 バイト文字が特定の環境下で正常に出力できません。 これはライブラリのバグではなく、 FlashPlayer 10.0 のバグです。 FlashPlayer 10.1 (10/05/10 時点では RC4) だとバグフィックスされているので、バグ対応することなく日本語の使用が可能です。（nod さんからTwitter で教えて頂きました。ありがとうございます。） Windows FlashPlayer 10.0 では日本語が全て文字化けして出力されます。 Macintosh FlashPlayer 10.0 では 2 バイト文字中に 1 バイト文字が入ると同要素内の以降の文字が出力されません。 Linux FlashPlayer 10.0 では何も出力されません。

原因

環境によって問題の現象が異なりますが、原因は同じ関数のバグによるものです。 ByteArray.writeMultiByte(hoge, 'unicodeFFFE')が FlashPlayer10.0 で 正常に動作していないことが直接の原因です。

対処法

FlashPlayer10.0 で encoding が 'UnicodeBigUnmarked' の場合、文字列を走査し、キャラクタコードを書き込みます。 jp.ferv.blog » Blog Archive » ByteArray に ‘unicodeFFFE’ を書き込む際のバグ に諸環境下でのバグの症状と対応策の詳細を書きましたので、合わせてご覧下さい。

バグFIX済み purePDF によるプレビュー

ローマ字・半角カナ・第一水準漢字・第二水準漢字を書き込んだ PDF を FlashPlayer 内で作成します。

• Windows FlashPlayer 10.0.45.2 plug-in
• Windows FlashPlayer 10.0.45.2 activeX
• Macintosh FlashPlayer 10.0.45.2 plug-in
• Linux FlashPlayer 10.0.45.2 plug-in

対応済み purePDF のソース・swc と Expample 用の as ファイルのダウンロード

purePDF_jp.zip

purePDF のライセンスは LGPL なので、継承して LGPL ライセンスでの配布となります。

変更箇所

バグのある関数をコールしている箇所を、 ByteArrayUtils クラス内のバグ対応用の関数をコールするように変更します。

• ActionScript
• PdfEncodings.as
• Source

//byte.buffer.writeMultiByte( text, ByteArrayUtils.getEncoding( encoding ) );
ByteArrayUtils.writeMultiByte( byte.buffer, text, ByteArrayUtils.getEncoding( encoding ) ); // modified by dsk(http://ferv.jp)

バグ対応用の関数です。 まず Capabilities.version から FlashPlayer のバージョンを判定します。 問題のないバージョンの場合は文字列を走査せず、 そのまま writeMultiByte() で書き込みます。 問題のあるバージョンの場合は文字列を走査しつつキャラクタコードを取得し、 2 バイトに収まるキャラクタコードの場合は writeShort() で書き込み、 収まらない場合は 4 バイトとして writeUnsignedInt() で書き込みます。

• ActionScript
• ByteArrayUtils.as
• Source

import flash.system.Capabilities;

• ActionScript
• ByteArrayUtils.as
• Source

/**
 * @author dsk (http://ferv.jp)
 */
private static var _specifiedVersion:Boolean = false;

/**
 * @author dsk (http://ferv.jp)
 */
private static var _isUnder10_1:Boolean;

• ActionScript
• ByteArrayUtils.as
• Source

/**
 * bug fix : fail to work "buffer.writeMultiByte( value, 'unicodeFFFE' )" at FP10.0;
 * @author dsk (http://ferv.jp)
 */
public static function writeMultiByte( buffer: ByteArray, value: String, charSet: String ):void
{
	if (!_specifiedVersion)
		_specifyVersion();
	
	if (!(_isUnder10_1 && charSet = 'unicodeFFFE'))
		buffer.writeMultiByte( value, charSet );
	else
		_writeUnicodeFFFEByte( buffer, value );
	
	buffer.position = 0;
}

/**
 * emulate writing utf-16 BE
 * bug fix : fail to work "buffer.writeMultiByte( value, 'unicodeFFFE' )" at FP10.0
 * @author dsk (http://ferv.jp)
 */
private static function _writeUnicodeFFFEByte( buffer: ByteArray, value: String ):void
{
	var len:int = value.length;
	var i:int, code:uint;
	for (i = 0; i < len; i ++)
	{
		code = value.charCodeAt(i);
		if (code < 0x10000)
			buffer.writeShort(code);
		else
			buffer.writeUnsignedInt(code);
	}
}

/**
 * specify the Flash Player platform and version
 * @author dsk (http://ferv.jp)
 */
private static function _specifyVersion():void
{
	var info:Array = Capabilities.version.split(' ');
	var versions:Array = info[1].split(',');
	var majorMinor:Number = parseFloat(versions[0] + '.' + versions[1]);
	_isUnder10_1 = (majorMinor < 10.1);
	trace('ByteArrayUtils.specifyVersion. to be implemented :', 'isUnder10_1 =', _isUnder10_1);
	
	_specifiedVersion = true;
}

ByteArray.writeMultiByte() メソッドには 2 バイト文字の 処理に不具合があります。 utf-16 BE (BigEndian) を書き込んだ際の諸環境で起こるバグの症状の確認の為の サンプルを wonderfl で書いてみました。 また、バグ対応のコードも合わせて確認します。

Windows FlashPlayer 10.0.45.2 plug-in/activeX

unicodeFFFE を指定したにもかかわらず shif_jis のキャラクタコードで書き込まれます。

Macintosh FlashPlayer 10.0.45.2 plug-in

2 バイト文字のみの間は utf-16 BE のキャラクタコードが正常に書き込まれますが、 1 バイト文字が混在すると以降のキャラクタコードが書き込まれません。

Linux FlashPlayer 10.0.45.2 plug-in

何も書き込まれません。

バグの対処法の解説

unicodeFFFE とは、utf-16 BE (BigEndian) なので String.charCodeAt(index);で一文字ずつですが取得可能です。 utf-16 では 1 文字を 2 バイトもしくは 4 バイトで定義しています。 つまり、文字列を一文字ずつ走査し、 charCodeAt() メソッドでキャラクタコードを取得し、 0x0000 〜 0xFFFF の範囲なら writeShort() メソッドで 2 バイトとして書き込み、 0x00010000 〜 0xFFFFFFFF の範囲なら writeUnsignedInt() メソッドで 4 バイトとして ByteArray に書き込めばよいことになります。
// ただし、日本語の場合は第二水準漢字まで含めても 2 バイト内に収まります。

Stratus2 で、どんなコードで何ができるのかを調べる（特に NetStatusEvent 周り）ついでにチャットアプリ作ってみた。 ソースは右クリックの「ソースを表示」から。重要な部分だけコメント付き。
要 Flash Player 10.1 - Adobe Labs - Downloads: Flash Player 10.1

Stratus って何？な人と Stratus1 は触ったけど Stratus2 って何？な人は Flash Player 10.1 と RTMFP （ピアアシストネットワーク） - akihiro kamijo に分かりやすく機能説明してある。 要するに、 FlashPlayer10.0 から 1Peer to 1Peer できるようになったけど、 10.1 ではさらに nPeer のグループを作ってその中で Peer to Peer できるってことみたい。

Stratus2 には、

• マルチキャスト (Application-Level Multicast)
• オブジェクト複製 (Object Replication)
• ポスト (Posting)
• ダイレクトルーティング (Direct Routing)

• Say 機能 → 「大量の送り手が時々ポストする」 → ポスト！
• Tell 機能 → 「誰にメッセージを送るかを指定する」 → ダイレクトルーティング！
• 過去ログ取得 → 「どのオブジェクトを持っているか或いは欲しいかという情報をグループ内に通知」 → オブジェクト複製！

Stratus2 関連のリンク

• Flash Player 10.1 と RTMFP （ピアアシストネットワーク） - akihiro kamijo : 上条さんによる Stratus2 の説明。
• Simple chat with P2P NetGroup in FP 10.1 — FlashRealtime.com : 開発環境のセットアップとサンプルコード。
• Adobe Labs - Stratus : AdobeLabs の Stratus トップ。"Signup for a Stratus beta developer key" からディベロッパキーを取得。
• Peer-assisted networking using RTMFP groups in Flash Player 10.1 | Adobe Developer Connection : コードと解説。
• NetGroup - BETA ActionScript 3.0 Reference for the Adobe Flash Platform : NetGroup クラスの ASDoc。
• Flash Player 10.1 と RTMFP - akihiro kamijo : RTMFP とは。
• Flash Player 10.1 と RTMFP （Stratus と接続性について） - akihiro kamijo : RTMFP の仕組みとできないこと。

同期処理でエンコード

zlib 圧縮率を 1 で、不透明な画像と透明な画像に対してフィルタの種類を変えてエンコードしてみる。

非同期処理でエンコード

非同期処理の注目点は、この例だと 12 回一気にコールしてるんだけど最後にコールしたところから順々に実行され、一個処理が終わると次の処理って感じにお行儀よく処理されていく。 これは Alchemy の機能だと思うんだけどコールしたのと逆順なのはなんか理由があるのかな・・・

あと、こっちはエンコード終了時に toXML() メソッドでちょっとだけデコードして情報を抜き出した XML を trace() してるから Firefox で FlashTracer 入れてる人は開いてみるといいかも。

拾った理由は、こんな感じ。 AS3 では ByteArray.compress() メソッドを叩くと、 deflate 圧縮して zlib 形式にフォーマットしてくれるんだけど、 冗長性のない ByteArray の圧縮は高速に処理できるけど、 PNG フォーマットに定義されているフィルタ処理で冗長化してから compress() すると処理にやたらと時間がかかる。 フィルタリングする前提だと、 zlib 圧縮率を低めにすれば十分高速に処理でき、 zlib 圧縮率よりもフィルタリングの有無の方がファイルサイズ縮小のメリットが大きいけど、 compress() メソッドでは zlib 圧縮率を設定できない。 あとは、 Alchemy だと非同期に処理するコードも簡単に書けるから、大きなサイズの BitmapData をエンコードする場合などもメリットありそうだし。

Alchemy の非同期処理は進捗とかを関数の参照渡しで C から AS の関数をコールして通知するんだけど、これって AS3 ライクじゃないんでイベントを発行する形にラップしてある。 あと、デバッグ用にちょっとだけデコードしてチャンクの情報とかを XML にして返す関数も実装。

てことで、 zlib と libpng を使って、 Alchemy で PNG クラスを作ってみた。サンプルの一番下に該当。

PNG フォーマットには圧縮効率を上げるフィルタという仕組みがあって、フィルタの仕組み自体は PNG の仕様書みながら実装できるけど、どのフィルタを使うのが最適なのかはアプリケーションに任されてるけど正直んなとこまで突っ込みたくないしってことで、 Alcehmy 使えばフィルタ選択もしつつ高速化もできるかと思ったけどそんなに甘くなかった。 結果は見ての通り。OSEEEEEEEEEEEEEEEEE!!

ただ、フィルタの自動選択の方はコンボボックスで PNG_ALL_FILTERS を選択してエンコードすると libpng が各スキャンラインに対して自動的に最適であろうフィルタを選択してくれてる気がする。 あと、 AS では引数もなにもなしで ByteArray.compress() の一行で済まされてしまう zlib アルゴリズムでの圧縮に対して、 Alchemy で zlib を使うと圧縮レベルを 0(無圧縮)～9(最大圧縮) で設定することができる。当然圧縮率上げると遅いけど。 ちなみに libpng のデフォルトのフィルタタイプは PNG_ALL_FILTERS で、圧縮レベルは 6 ぽい。

速度重視なら Optimized PNGEncoder with filters 使って、ファイルサイズをある程度考慮しないとだったら Alchemy の PNG クラス使うとかそんな感じかなー・・・なんにせよ選択肢増えたってことでよしとするか・・・

とりあえず Alchemy の練習で libjpeg を使ってエンコードする関数を書いてみた。今回は .gg から .c と .as を書き出してくれる Alchemy についてる GlueGen っていうツールを使った。 .c は次の工程の .swc 書き出しに使って、 .as はその .swc 内の関数への繋ぎ的な役割をしてくれるクラスファイルで、 (new CLibInit()).init(); とかの定型句的なコードを勝手に書いてくれる。だけど、例えば関数の引数のデフォルト値ってどうやって書いとけばちゃんと .as に反映されるのかとかよくわかんない事だらけ。

例の Alchemy - asynchronous jpeg encoding を見た時、 bytearray.org の JPEGEncoder と比較して 10 倍位パフォーマンス良いように見えた segfaultlabs.com の JPEGEncoder だけど DebugPlayer で見てたからだった。普通の Player だと、 2 倍位しか違わなかった。いや、 2 倍でもすごいんだけど 10 倍の衝撃がすごすぎて・・・（FlexBuilder ってリリースビルドしても DebugPlayer で見ると遅いの？↑のはFlashDevelop で Release 書き出しだけど DebugPlayer から見ても速く動いてる気がするけど。）

大体 segfaultlabs.com のとこのと同じくらいのパフォーマンス出たからこの方向で PNG もやってみよっと。

PNG フォーマットで定義されてるフィルタの種類は5種類。

• None - 該当バイトをそのまま使用 (as3corelib の PNGEncoder はこれ一択)
• Sub - 該当バイトと左のピクセルのバイトとの差分を使用
• Up - 該当バイトと上のピクセルのバイトとの差分を使用
• Average - 該当バイトと左/上のピクセルのバイトの平均値との差分を使用
• Paeth - 該当バイトと左/上/左上のピクセルのバイトのうちの最近傍値との差分を使用

ていう感じ。どのフィルタを使うのが圧縮率が高いかは対象の画像に依存する。

ファイルサイズは 1 / 5 くらいになるけど、処理時間は倍以上かかっちゃう。このまま None 以外のフィルタ使うとサーバ資源は節約できるけどユーザのストレスは倍増間違いなし・・・ あ、Alchemy の出番ですね！！まだ Cygwin のセットアップも終わってないけど！！

// 関係ないけど Wonderfl でコードが 1000 行越えるとソースコードのプレビューのインデントとかカラーリングとかが壊れちゃいました。

PNGフォーマットはJPGフォーマットのように複雑な変換処理がない単純なフォーマットなので、コード量が少く最適化箇所も少ない。ただ、複数回エンコードしたり、サイズの大きな BitmapData をエンコードする際にはメリットがでてくるんじゃなかろーかと。

処理速度比較の為に as3corelib の PNGEncoder と同じく PLTE チャンクは実装せず、フィルタオプションは 'None' 一択で実装してる。 as3corelib にはない機能で、 BitmapData が不透明時の分岐を実装した。これをしとくことで BitmapData.transparent == false の BitmapData をエンコードした時にファイル容量が軽くなるはず。

最適化箇所をざっくり挙げとくと、 for 文の length をあらかじめ取得しとくとか、 for 文の中で何度も同結果の分岐を挟まないとか、 Vector を使うとかっていう最適化の基本的なところから、エンコード毎に使う PNG シグネチャ・ IEND チャンク・ CRC テーブルを定数にして使い回したりだとか、何度も同結果の null チェックしないとか、無駄な型変換をしないとかそんな感じ。
サイズや透明・不透明によって違うけど、だいたい 25% くらい高速化してる気がする。