アカウント名:
パスワード:
半透過ウィンドウは Windows 2000 の時点で API 用意されてますが。
ただ、極端に処理が遅くなるため、Longhorn ではここまで軽量に処理できるようになりましたよ、という事を見せるのがポイントでしょう。
このシステムが実現するとなにがおこるか、というと、 プログラムに「再描画」の処理がいらなくなるのです。 その内容が破壊されないことをシステムが保障して、 複雑な再合成処理は下層(ハード)のお仕事。
まあ、アプリケーションとしては、従来環境のためと、 あと初回の描画のために OnPaint 処理をき
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
ずれてますね (スコア:1)
はっきりいって2Dのディスプレイに3Dのインタフェースを書き出すのは逆に使いにくくなると思います。タレコミにあった3D Desktop?なんかはかなり使いにくそう。3Dっぽい効果くら
Re:ずれてますね (スコア:0)
半透過ウィンドウは Windows 2000 の時点で API 用意されてますが。
ただ、極端に処理が遅くなるため、Longhorn ではここまで軽量に処理できるようになりましたよ、という事を見せるのがポイントでしょう。
Re:ずれてますね (スコア:1)
裏に隠れたWindowの描画をはしょれなくなっちゃうからそのぶんだけ重くなりそうですねぇ
今回は裏のWindowを頻繁に書き換えるやつじゃなかったからそこら辺は露呈しなかったんでしょうけど
次にデモやるときは ムービー3つぐらい重ねて重くならないことをアピールしてほしいもんです
分かってない人多いなあ (スコア:0)
というデモなんですけどね.
Re:分かってない人多いなあ (スコア:0)
このシステムが実現するとなにがおこるか、というと、 プログラムに「再描画」の処理がいらなくなるのです。 その内容が破壊されないことをシステムが保障して、 複雑な再合成処理は下層(ハード)のお仕事。
まあ、アプリケーションとしては、従来環境のためと、 あと初回の描画のために OnPaint 処理をき
Re:分かってない人多いなあ (スコア:1)
#たれ込みのリンク先にあったかな?
これが本当だとすると、各バッファ(ウィンドウ)の描画内容をどこかでメモリに保存する必要があると思うんですが、それはOSがやってくれる
Re:分かってない人多いなあ (スコア:1)
>でもそれって、鬼ほどメモリ食べるのでは…?
120%うろ覚えですが、たしかBeOSだかも、既にそれをやってるとか言ってませんでしたっけ?
必要メモリっすか?俺も素人(ぉ)なんで乱暴すぎる推測ですが、
n個の窓(デスクトップ含む)が最大化状態の自分の描画結果を保持してるとすると、
1024*768(笑)*4(Pixelが32bitだとして)*n byteが有ればいい、のだよねえ?
だとすると3MB*n。
まあ今時(のWinユーザー)なら許せるんじゃない?
100MBくらいの余剰メモリ空きが(メイン)メモリにあるのは珍しいことじゃないんだから。
#自分のpc(win)にゃbcがinstallされてないので焦ったが、ruby -eで済むことに気付いて助かりました(ぉ
>あるいはメモリが足りなくなったときとかは、どうなるんでしょう?
俺のほうでは、仕事鯖Unixマシンのメインメモリ(swap込みでも)が頻繁に「足りなく」なっていたんですけど(笑)。
つまり、足りなくなったら動かなくなる、ってのは大昔からのコンピュータの仕様なのではないかと。
絵の管理ポリシーが空きメモリに合わせて動的に替わるように作ってあるかどうかは、知りません。
#でもメモリが不足がちなときにアプリに頻繁な再描画を強いると、悪循環になりそう。
Re:分かってない人多いなあ (スコア:0)
Re:分かってない人多いなあ (スコア:1)
いや、私もよく使いますけど(ぉ
#と、このように
#まーともかく、とりあえずLonghornで早くプログラム組んでみたいなあ
#てことでファイナルアンサー。
#うーん、いいデモだ。