アカウント名:
パスワード:
半透過ウィンドウは Windows 2000 の時点で API 用意されてますが。
ただ、極端に処理が遅くなるため、Longhorn ではここまで軽量に処理できるようになりましたよ、という事を見せるのがポイントでしょう。
このシステムが実現するとなにがおこるか、というと、 プログラムに「再描画」の処理がいらなくなるのです。 その内容が破壊されないことをシステムが保障して、 複雑な再合成処理は下層(ハード)のお仕事。
まあ、アプリケーションとしては、従来環境のためと、 あと初回の描画のために OnPaint 処理をき
これはXで言うところのBacking Store/Save Underと同じようなものでしょうか? Xサーバはユーザプロセスでメモリ使い放題なので, 10年前から実現されていましたけど.
ディスプレイドライバをリリースしているベンダーに文句を言いましょう。ドライバレベルの仕様ではそういう機能が定義されているのにだーれも実装しなかったんだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ずれてますね (スコア:1)
はっきりいって2Dのディスプレイに3Dのインタフェースを書き出すのは逆に使いにくくなると思います。タレコミにあった3D Desktop?なんかはかなり使いにくそう。3Dっぽい効果くらいならまだ許せますが・・・
透けて下のwindowが見えるってのは、過去にもフリーウェアなどでありましたが、それがOSレベルでサポートってだけでしょうか。まあ画面が狭いノートなら便利かも。
Re:ずれてますね (スコア:0)
半透過ウィンドウは Windows 2000 の時点で API 用意されてますが。
ただ、極端に処理が遅くなるため、Longhorn ではここまで軽量に処理できるようになりましたよ、という事を見せるのがポイントでしょう。
Re:ずれてますね (スコア:1)
裏に隠れたWindowの描画をはしょれなくなっちゃうからそのぶんだけ重くなりそうですねぇ
今回は裏のWindowを頻繁に書き換えるやつじゃなかったからそこら辺は露呈しなかったんでしょうけど
次にデモやるときは ムービー3つぐらい重ねて重くならないことをアピールしてほしいもんです
分かってない人多いなあ (スコア:0)
というデモなんですけどね.
Re:分かってない人多いなあ (スコア:0)
このシステムが実現するとなにがおこるか、というと、 プログラムに「再描画」の処理がいらなくなるのです。 その内容が破壊されないことをシステムが保障して、 複雑な再合成処理は下層(ハード)のお仕事。
まあ、アプリケーションとしては、従来環境のためと、 あと初回の描画のために OnPaint 処理をき
Re:分かってない人多いなあ (スコア:1)
#たれ込みのリンク先にあったかな?
これが本当だとすると、各バッファ(ウィンドウ)の描画内容をどこかでメモリに保存する必要があると思うんですが、それはOSがやってくれるわけでしょうか?
でもそれって、鬼ほどメモリ食べるのでは…?
あるいはメモリが足りなくなったときとかは、どうなるんでしょう?
#再描画が呼ばれる頻度が減る、くらいなら理解できるけど…
Re:分かってない人多いなあ (スコア:1)
ですから有効に使いましょうということで、いわゆる富豪プログラミングですね。
Re:分かってない人多いなあ (スコア:1)
>でもそれって、鬼ほどメモリ食べるのでは…?
120%うろ覚えですが、たしかBeOSだかも、既にそれをやってるとか言ってませんでしたっけ?
必要メモリっすか?俺も素人(ぉ)なんで乱暴すぎる推測ですが、
n個の窓(デスクトップ含む)が最大化状態の自分の描画結果を保持してるとすると、
1024*768(笑)*4(Pixelが32bitだとして)*n byteが有ればいい、のだよねえ?
だとすると3MB*n。
まあ今時(のWinユーザー)なら許せるんじゃない?
100MBくらいの余剰メモリ空きが(メイン)メモリにあるのは珍しいことじゃないんだから。
#自分のpc(win)にゃbcがinstallされてないので焦ったが、ruby -eで済むことに気付いて助かりました(ぉ
>あるいはメモリが足りなくなったときとかは、どうなるんでしょう?
俺のほうでは、仕事鯖Unixマシンのメインメモリ(swap込みでも)が頻繁に「足りなく」なっていたんですけど(笑)。
つまり、足りなくなったら動かなくなる、ってのは大昔からのコンピュータの仕様なのではないかと。
絵の管理ポリシーが空きメモリに合わせて動的に替わるように作ってあるかどうかは、知りません。
#でもメモリが不足がちなときにアプリに頻繁な再描画を強いると、悪循環になりそう。
ビデオカードがやってくれます (スコア:0)
だから,3Dなんて言われてるわけですが.
要求スペックを見ると,ビデオメモリは充分にあると思いますが,
不足した場合の挙動は確かに気になります.
DirectXのレベルでうまく扱ってくれるのかもしれません.
Re:分かってない人多いなあ (スコア:0)
Re:分かってない人多いなあ (スコア:1)
Re:分かってない人多いなあ (スコア:1)
あとゲームのように、VGAカードにくっついたビデオメモリを使って高速化しているアプリが居れば、さらに使えるバッファは減りますし。
#まあシステムメモリから回すとかスワップするとか手はあるけど…
困ったときのAGP (スコア:1)
こういうときのためのAGP8xなんでしょうね?
8x。
・・・なんで8xなんだよ!
内蔵AGP4x買ったばっかなのに。
Re:分かってない人多いなあ (スコア:1)
Re:分かってない人多いなあ (スコア:0)
アプリの責任でない描画領域の破壊が起こらないため、
再描画をしなくてよいということになります。
Re:分かってない人多いなあ (スコア:0)
Re:分かってない人多いなあ (スコア:1)
でもブラウザやワードの要に全画面表示なアプリで85枚ならあり得るかなあ、と思います。
たぶん、1バッファあたりはもっと少ないでしょうね。その代わり、使われるバッファは実際には200バッファくらいは軽く越えるんじゃないでしょうか。
Re:分かってない人多いなあ (スコア:1)
間抜けにもさっぱり気づきませんでした。
3Dアクセラレータの使い倒そう→窓描画=テクスチャ描画、
という流れだと読んでいて、「それでどうなるの?」の方は
「あー、ぐるぐる回ったり変形させたり自由自在なんだ。ふーん」
くらいで思考止まってました。
いやもう、まさに枝タイトルの通り、分かってない人でした。はい。
Re:分かってない人多いなあ (スコア:1)
いや、私もよく使いますけど(ぉ
#と、このように
#まーともかく、とりあえずLonghornで早くプログラム組んでみたいなあ
#てことでファイナルアンサー。
#うーん、いいデモだ。
Re:分かってない人多いなあ (スコア:1)
どーも3Dに視点がいっちまってそこまで頭が回ってなかった
アプリから見ると描画に関してはずっと最前面で動いてるのと同じになるわけだ
初期化してあとは本当に必要なところを書き換えるだけでいいわけだ
でも 親windowレベルの話だったらちょっと物足りないかもしれないな
タブで子window切り替えとかやってると結局子windowの描画処理書かなきゃならんし
まぁそれでも 確かに進化してる
2000→XPみたいなバージョンアップとはあきらかに違ってくるわけだ
Re:分かってない人多いなあ (スコア:1)
これはXで言うところのBacking Store/Save Underと同じようなものでしょうか? Xサーバはユーザプロセスでメモリ使い放題なので, 10年前から実現されていましたけど.
Re:分かってない人多いなあ (スコア:0)
全アプリが、VBのフォームのAutoRedrawプロパティをTrueにしたようなもんですな。
# メモリは食うけど、サンデープログラマの使い捨てプログラムには強い味方。
Re:ずれてますね (スコア:0)
ディスプレイドライバをリリースしているベンダーに文句を言いましょう。ドライバレベルの仕様ではそういう機能が定義されているのにだーれも実装しなかったんだ。
Re:ずれてますね (スコア:0)