[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 02/26 00:40 / Filesize : 251 KB / Number-of Response : 842
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【初心者】Java質問・相談スレッド121【歓迎】



158 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 18:04:23 ]
>>155
う〜ん、なので私自身は最初に「伝統です」と答えたのです。
正直あなたがどの程度の知識を持ち合わせているのか分からなかった
ので、「どうしてそのような伝統なのか」という事情を具体例を挙げて
説明しようと試みました。
どうやら完全にスキルを読み違えた返答になってしまったようで申し訳
ありません。

確かに私はGUI方面からは暫く離れた古い人間で、しかも当時の専門
はどちらかというとVRとかいったやや特殊な表示方面でした。
ちょっと昔の事例ですが、CaveLib辺りを弄くっていました。
で、同期には大変苦労しました。

確かに仰る通り計算と表示は必ずしも同期する必要はありません。
(特にVRでは「しない」前提でないと設計できない事が多いです)
問題は、ユーザの操作シーケンスと計算(というかアプリケーションが
実現する処理一般)の内容は一致させる必要がある、という点です。

で、これを実現するためには描画は別CPUに丸投げ、とは案外いか
ないなというのが実感でした。
少なくとも再描画周りであればLayoutまではきっちり首に縄を付けて
おかないと、「座標xyzをクリック」というイベントを「部品Aをクリック」
といった論理イベントに解釈するところで大いにハマります。
でも分散しないとフレームレートが上がらない、ので苦労しました。

なので、仮に最近のOOを用いたアプローチでより洗練された設計
モデルが実現されているのであれば大変興味があります。
(興味、ですよ。今はこの分野からは離れているので。)
もしある程度確立したモデルがあれば教えていただけると幸いです。
あるいは参考になる実装なりプロジェクトがあれば幾つか挙げて
もらえないでしょうか?






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<251KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef