nogの日記: Mac OS XのJava 5
日記 by
nog
結局は使っていないJavaで作ったイメージビュアをいじっている。まず気になったのは動作の重さ。何とかならないものかと思いソースを追っかけると、重複した操作をしているところを発見。フォルダの中のファイルを表示させた場合、1/3のスピードになったと思うが、それでも早くはない。
どうしたものかと思い、googleで適当に検索するとImageIOを思い出す。昔試してみたけど、結局は使えなかったんだよなぁって思ってまた試してみる。が、特定のJpegフィアル(ちなみに真鍋かをり)でどうもうまく動作しない。
サムネイル表示するために、まずイメージを取得してサイズを取得するのだが、そのあと縮小表示したイメージ作成のところでつまずくようだ。
現在は Toolkit.getImage()を使っており、ImageIOではImageIO.read()を使う。どちらもインターフェイスのImageを返すが、インスタンスのクラスの名前を実際に表示(Object.getClass().getName())してみると、前者は apple.awt.OSXImageを返し、後者はjava.awt.image.BufferedImageを返す。
前者は使えるので結局は(イメージの取得に関しては)変更がない訳だが、、、
ImageIOが早いと言う保証もないし、とりあえずいっか(ぉぃ
Toolkitは使わない方がいい (スコア:1)
ImageIOは,まだまだ問題があるもののAPIとしては良く出来ていると思うので,Toolkit#createImageは使わない方がいいと思います.
いろいろ理由があるんですが,MacOS Xでは問題ないと思いますが,Toolkit周りを使うと,Windowリソースを使うので,LinuxなどではXが起動してないと使えないという欠点があります.
一方ImageIOは画像処理を独自のエンジンを持っていてWindowシステムとは独立して動作させる事が出来るし,もともとImageIOは便利なmethodをたくさん持っているので,こちらを使うのが正解だと思います.
ただし欠点もあって,今のところImageIOの読み込みはパフォーマンスがちょっと悪い(特に大きめな画像(1024x768とか))とか,メモリリークがあるとか(私の知っている限りWindowsなど)あるのですが,これは徐々に改善していくと思うのでもうこっちでいいんじゃないかと.
それとまだいろいろ利点があって,BufferedImageは,getWidth,getHeightですぐに画像の大きさを取得できたり,1ピクセルごと読み書きできたり便利なので,いまさらImageを使う気がしないというのもあります.BufferedImageのパフォーマンスは思ったよりもいいですしね.
FreeHEPなどで検索すればわかりますが,GIFの読み書きなどもSPI(Service Provider Interface)で提供されつつあるので,簡単に追加拡張でき,便利です.
それと別件.Tiger(J2SE 5.0の方)がリリースされるという噂もありますし,Tiger(Mac OS Xの方)もありますし,新しいAPIに手を出していい次期かもしれませんよ.
Re:Toolkitは使わない方がいい (スコア:1)
そんなわけで、javax.imageio.*を使うと画像ファイルを(多分)全部開かなくてもサイズが取得できそうなんで、指定したサイズ(getScaledInstanceじゃなくて、コンストラクタで指定するイメージで)でImageのインスタンスが作れればなぁって思ってるんですが、似たようなメソッドはあるもののそのものズバリはないですねぇ、、、探し方たりないかなぁ
ImageIO (スコア:1)
ImageIOはパフォーマンスが悪かったのと、アニメーションGIFが再生できなかったのが理由でした。
アニメーションGIFはBufferedImageのつくりから考えて無理でしょうが、パフォーマンスは改善されたのでImageIOもいいかもしれませんね。
Re:ImageIO (スコア:1)
#すごいハンドル名ですね:-).いや私もそうなりたいかも.
なるほど,BufferedImageで(自動的に描画される)アニメーションGIFはどうしようもないですね.Imageと違って,Componentと深く結び付いて再描画とか考えていませんもんね(^^;.
私の場合は,静止画か,動画処理とかの表示に使うことが多いのでアニメーションGIFとか目から鱗でした.
Re:ImageIO (スコア:1)