今時X_clientとX_serverを分ける必要あるだろうか？

**名無しさん＠お腹いっぱい。** · 05/03/13 21:45:09

俺は無いと思う。
そんな機能をつけるよりもより軽く、より高速な物として欲しい。

**16=40=49=54** · 05/03/15 23:29:05

うひ、なんかえらい叩かれてるな(w

>>54 の書き方も悪いけどクラサバ自体を無くせなんてことは
言ってないんだよね。スレタイにもあるように、「X のクラサバ」を
無くすって考え方もあるよね、将来鬼描画するならば。
って言ってるだけで。

要するに >>56 の

>テクスチャの話もgimpの話も、現在のXのままでも、ローカルで
>走らせれば解決する話にすぎなくて、クライアント・サーバー
>モデルを捨てる必要があるという理由になってないじゃん。

って話。ローカルで走らせることで解決する話なら、 X の
クラサバモデル無くてもいいじゃん? ってコト。

# 念のため、パフォーマンスを求める場合だよ。
# DRI レベルの話じゃない。今更 2D なんて、どーでもいいっしょ。
# あと今の X から無くせって言ってるわけでもない。
# 現に今も飛ばしたウィンドウから書き込んでるし。

**16=40=49=54=76** · 05/03/15 23:29:50

すまん、しつこいね。これ最後。

でまぁ、色々と考えてみたんだけど、描画タイミングが通常の X アプリ
程度なら実はクラサバでもイケるかもって気はしてきた。
ディスプレイリストもテクスチャもサーバ側に乗るだろうし。
ただ、遅いネットワーク経由の今の X でデカいイメージを扱うのと
似たような感覚なので、サーバからリソース消えたらえらいペナルティ
喰らうけど。(と、妄想拡張サーバの仕様を勝手に持ち出してみる)

# GPU だけじゃなく CPU プログラムもサーバに転送できれば毎フレーム描画も
# 可能だよね。って、それって結局ローカルで動かしてるだけじゃん。みたいにならん?

**名無しさん＠お腹いっぱい。** · 05/03/15 23:38:31

>>76
> って話。ローカルで走らせることで解決する話なら、 X の
> クラサバモデル無くてもいいじゃん? ってコト。

おまえ何言ってるか自分でわかってる?
さんざっぱら, extension を適当に定義すれば...
って, みんなが言ってるのに.

> # DRI レベルの話じゃない。今更 2D なんて、どーでもいいっしょ。

へ? DRI って GL を高速描画するために考えられた
メカニズムだったはずなんだが.

**名無しさん＠お腹いっぱい。** · 05/03/15 23:39:13

>>76
DRIは2Dでは使っていないのだが、何か根本的な部分で勘違いしていないか?

**名無しさん＠お腹いっぱい。** · 05/03/15 23:41:38

>Xで動くアプリは結構手が入ってるけど
アプリに手なんか余り入ってないと思うのは僕だけ？

**名無しさん＠お腹いっぱい。** · 05/03/15 23:43:28

> って話。ローカルで走らせることで解決する話なら、 X の
> クラサバモデル無くてもいいじゃん? ってコト。

アホ？
ローカルで走らせると困る応用があることは、このスレでも
出てるでしょ。

・クライアントサーバーモデルを保ったまま、ローカルで走らせる
　→ gimp も OK。リモートから使いたい場合も OK。
・クライアントサーバーモデルをやめる。
　→ gimp は OK。リモートから使いたい場合は駄目駄目。

どちらがいいかなんて、自明だろ。

> # 念のため、パフォーマンスを求める場合だよ。

そういう場合でも、ちゃんとボトルネックがどこにあるか計測して
からやるのが当然だろ。単なる思いつきでクラサバやめればぁ？
なんて言ってるのは、エンジニアリング以前。