読書会(Filthy Rich Clients)第3回議事録

[ 戻る ]

Java読書会 「Filthy Rich Clients」を読む回（第3回）議事録

日時 : 2009/6/27(土)　10:00-17:00
場所 : 高津市民館　第6会議室
出席者：今井、岩室、遠藤(書記)、小棚木、高橋(徹)、高橋(智)、
　　　　根本、高嶋、吉本、村山、前山
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

- windowsの人はanti aliasが好きでない人がおおい
- getScaledは遅くて使えそうにないのになぜ紹介されているのか
　- 標準に用意されていて、使ってしまうと遅いから注意しようという
　　意味では
- getFasterScaledinstance
　- imgをBufferedImageにキャストしてretに代入しているのはなぜか？
　- 最初はBufferedImageではなかったのか？
　- 配布されているソースではキャストはなかった
　- 最後の方に出てくる「scratch bufferがターゲットサイズよりも大きかったら」
　　の部分は何をしているのか？
　　- do〜whileの中で作られるscratch bufferは、
　　　大きなバッファを作って使いまわしているので
　　　最終画像と関係ない領域を除外している
　- フラグが多くて読みづらい 
- 誤植、「読者のみなさん？」

* 5. performance
- 脚注のchetは何？
　- 著者の一人
- Swingに任せるよりも、自分でクリッピングを尊重した方が早いのはなぜか
　- Swingは汎用的な方法でしか処理できないが、アプリ側なら最適な処理ができるから
- 結局、getClipBounds以上のことはするなということか？
　- 物体全体を描画するかどうかの判断はアプリでやるけど、
　　物体のどの部分がクリップの中に入っているかまで計算するほどではないだろう

** why should care

- 5-6-5の16bitフォーマットを32bitに変換するとき、
　なぜ各要素を上位ビットにマッピングするのか、
　- なるべく24bit RGB空間全体にマッピングするため
　- 元データの全ビットが1の時に0xFFFFFFにならなくてよいのか
　- 脚注7によれば、最後にsrcとorしていて0xFFFFFFになるようにしている

- 複数のことなる深さを使用するとは？
　- ひとつのPCに複数のディスプレイが接続されている場合
　- 最近はひとつのビデオカードで複数のディスプレイをつなげられる

- 2番目のcreateCompatibleImageは、imageをもらっているわりには、
　getTransparencyしか使っていないので分かりづらい

** 管理画像
- 管理画像は訳語がしっくりこない
　- managed codeなどの用語はMSが作って、最近広まりつつあるのだろう
- 宿題
　- DataBufferGrabberを自分のマシンで実行して結果を報告する
　- 報告の際には、CPU、システムメモリ、GPU、VRAMの接続関係を図に書いて
　　なぜそのような結果になったのかを考察する

- 画像への頻繁なレンダリング
　- バックバッファとは何をさすか？
　　- ダブルバッファの説明のときはオフスクリーンのメモリ領域と言っている
　　- P137だと意味が違いそう？

* コンポジット
- SrcOverの図は正しいのだろうか？
　- 印刷上の問題かもしれない

-　BlendingContextは何?
　- 紙面上 AddComposite、AddContext となっているものは
　　サンプルコードでは、BlendComposit、BlendingContextとなっている

- AddContextは、サイズの違うものを合成できるのか
　- width、heightは2つの画像のminをとっているのでできそう
　- 位置はどうなるのか？
　- 多分、左上でそろえている。位置の調整もしたいなら実装を変える必要がある。
　- 回転をCompositの中でやってもよいのか？

* グラデーション
- DepthButtonの濃いほうの色は、青みがかった灰色か？



P191まで終わった。

[ 戻る ]