JP"E"GEncoder.as

com.adobe.images.JPGEncoder はFlexの標準ライブラリではないものの、adobe謹製ということで広く使われておったようですが、いつの間にかFlexの標準ライブラリに mx.graphics.code.JPEGEncoder というクラスが加えられていました。
これは mx.graphics.code.IImageEncoder というインタフェースを実装したクラスなんだけども、ソースを見るにアルゴリズムや入ってるコメントには大きな違いは無い模様。ですが、何らかの最適化がなされているのかも？という期待が無いことも無いです。
じゃあ、こっちのアルゴリズムでもイベントを送出するように改造したろうかなぁ。
あ、でも encode() の戻り型がByteArrayじゃなくなるから IImageEncoder は実装出来なくなるね。IImageEncodingDispatcher とか作ればいいのかなあ。いや、いらねぇなあ。

そういえばPNGEncoderも進捗イベントを送出するように改造しようと思ったこともあるんだけども、ソースを見るに、ByteArray.compress()という見慣れないメソッドが使われていた。標準のバイト配列の圧縮処理を利用しているらしい。巨大画像のエンコードで時間を喰うとしたらおそらくはコレだろうから、断念・撤退したのだった。

かならず同じところで

よくやる間違いについて自戒メモ。

僕ァ、比較的低級な演算子が好きだナァ。
ビット演算子とか、三項演算子とか。あとswitch構文も好きだナァ。
で、好きな筈のビット演算子でよくハマってしまうミスについて。

例えば奇数を求めるとき

i << 1 + 1

なんてうっかり書くと、目的の出力は得られないしエラーも出ないってんで、参っちまいます。
+演算子のほうがビットシフト演算子よりも優先されるために、上の式は

i * 4

と同値になってるんですな。

あと、ある整数が偶数かどうかの真偽値を

i & 1 == 0

とか書いちまったりするんですが、これも間違い。
関係演算子のほうがビット演算子よりも強いんですな。つまり上の式は、

i & false

と同値になっちまってんです。javaだとエラーが出ますね。
比較的柔軟な言語であれば false=0 で解釈されるので、結果はいつもfalse(奇数)になってしまう。

で、大事なことは何かってぇと、演算子の強弱関係を把握する、ってことじゃなくて、例え若干の冗長表現になろうと、明示的に括弧で括ってやる、ってことなんだろうな。それが真心ってもんじゃぁねえかな。
上の例だと

( i << 1 ) + 1

( i & 1 ) == 0

と書けば所望の結果が得られますな。
これで何度つまづいたことか。

エンコードをどうにかした話

まず、コードが見づらいので google-code-prettify を導入。

ちょっと長くなります。
まずオリジナルのJPGEncoderから。ソースはここから引用。

エンコードをどうにかしたい話

例のアレ、ようやくカタチになったのだけど、不安なところが（今のところ）ひとつ。

JPGEncoderはencodeメソッドひとつでBitmapDataがBytesArrayになる簡便さがある反面、エンコード最中は他のメソッドが一切実行できなくなります。Flex GUIのエフェクトやアニメーションなども停止するので、メガピクセル超の画像をエンコードする際などは、非常に不安な気持ちで数秒～十数秒待たされることになります。
フリーズじゃないかと疑われてしまうのではないか、と。
苦し紛れにProgressBarなどを表示させてみましたが(進捗情報が得られないので漫然とバーが動くだけ)、そのアニメーションすら停止するので、フリーズの不安を和らげる効果がありません。

ばぐじゃね？

パースエディタに下絵を表示させるべく、昨日一日ずっとMXMLと格闘して、なんとか見えてきた。データバインディングのことも少しずつ分かってきましたよ。

さて、どうもうまくいかないところが一カ所。
下絵を読み込む前は「下絵を破棄」っていうアイテムは初期状態では enable="false" になるようバインディングを施してる筈なのだが、ならない。
で、セパレータで挟んでアイテムをコピペすると、コピペしたアイテムはバインディングが出来てる！？まったく同じコードなのに？
（ちなみにセパレータを挟まないと全部バインディングに失敗する！）

どうも、これはバグじゃなかろうか。
で、回避方法は以下。

ロールシャッハに向けて(4)

できたー！
けど反省点も色々。今回考えたアルゴリズムは「厳密に直線上の点」とか「厳密に同一の直線」に弱い。
図形の辺と辺が重なったときどっちが外側でどっちが内側か分からなくなっちゃうんだな。
なので誤魔化しを行った。反転図形を作るとき、ホンの少しｙ値をずらしてる。



さて、何が見える。

ロールシャッハに向けて(3)

色々細かいところを潰して、だいぶ安定してきた。
黄色いラインが元になってる多角形。

あとはシンメトリーにするだけだねぇ。