今時X_clientとX_serverを分ける必要あるだろうか?
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。
05/03/13 21:45:09そんな機能をつけるよりもより軽く、より高速な物として欲しい。
0002名無しさん@お腹いっぱい。
05/03/13 21:48:420003名無しさん@お腹いっぱい。
05/03/13 21:50:51バックエンドのスパコンの出力を可視化するのはどうやればいいんだ?
0004名無しさん@お腹いっぱい。
05/03/13 21:52:05なんでそんなスペシャルケースを持ってくるんだ?
0005名無しさん@お腹いっぱい。
05/03/13 21:54:000006名無しさん@お腹いっぱい。
05/03/13 21:55:47スパコンからデスクトップまでをカバーする必要なんてまったく無い。
0007名無しさん@お腹いっぱい。
05/03/13 21:58:120008名無しさん@お腹いっぱい。
05/03/13 22:01:04何で誰も作らないの?
0009名無しさん@お腹いっぱい。
05/03/13 22:05:07どっかそこらへんのスレと重複。以降はそちらへ。
0010名無しさん@お腹いっぱい。
05/03/13 22:15:49X protocol 自体トランスポートは選ばないから、それなりの
extension 定義してやれば server/client モデルって部分も
隠蔽できるはず。ある意味 DRI がいい例だ。
問題なのは GPU を作っているメーカが、GPU の仕様を公表し
ないことだと思う。何かしたくても、「GPU つつけないから
DRI がいつまでたっても早くならない。」ってのが、現状だ
と思うけど。
0011名無しさん@お腹いっぱい。
05/03/13 22:23:06http://pc5.2ch.net/test/read.cgi/unix/1023264974/
0012名無しさん@お腹いっぱい。
05/03/13 22:48:46これからはAgentモデルだな。
0013名無しさん@お腹いっぱい。
05/03/14 02:23:290014名無しさん@お腹いっぱい。
05/03/14 02:29:140015名無しさん@お腹いっぱい。
05/03/14 05:02:21そういうあなたに xset m ほげほげ
0016名無しさん@お腹いっぱい。
05/03/14 10:43:24あちこちから ssh に乗せて X のウィンドウ飛ばさない?
0017名無しさん@お腹いっぱい。
05/03/14 12:51:160018名無しさん@お腹いっぱい。
05/03/14 13:02:11軽快に動くんだけど
0019名無しさん@お腹いっぱい。
05/03/14 16:26:51飛ばす飛ばす。
東京にしかライセンスがないソフトを大阪から使ったり。(w
0020名無しさん@お腹いっぱい。
05/03/14 16:40:00ご家庭のWinをリプレイスするようなスタンドアロンのデスクトップ端末としてのUNIXの登場で、
その時はXってシステムは冗長だから、もっと低レベルで動く軽いWindowSystemが欲しい。
ってことなんじゃないかなと推測。
まあ言いたい事も解らなくもない。
0021名無しさん@お腹いっぱい。
05/03/14 18:38:55これも結局>>10がいう通りの理由で、パフォーマンスではXに対する優位性はない。
QtとかGTKがそこそこ使えるようになってきた昨今、大抵の事はXを直でさわる事なしに
出来ると思うけど。
0022名無しさん@お腹いっぱい。
05/03/14 18:44:540023名無しさん@お腹いっぱい。
05/03/14 19:11:18■■■X11不要論■■■R2■■■
http://pc5.2ch.net/test/read.cgi/unix/1099755829/
0024名無しさん@お腹いっぱい。
05/03/14 22:50:41その通りです。言葉足らずでした。
>>23
そのスレはCUI or GUI的なスレだと思うので、重複ではないと思います。
0025名無しさん@お腹いっぱい。
05/03/14 23:08:14>>10が書いているように、別にXだからって、必ずしも
クライアント・サーバモデルのオーバヘッドがかかる
わけではない。(実際、XでもDRIを使えば、クライアントが
直接描画できる。)
あと、もはやCPUもメモリもあり余ってるんだから、いまさら
クライアント・サーバモデル程度では、まったく負荷的問題
にならない筈。
それどころか、今後はどうも単一CPUで複数の仮想マシンを
運用するような流れになりそうなので(IntelのVanderpool
Technologyとか)、複数の仮想マシンを単一のコンソールから
利用できるX的な作りの方を、時代が必要といるような。
Windows的なやり方だと、ウィンドウ単位ではなくてスクリーン
単位で切り替える必要があるので、とっても不便。
0026名無しさん@お腹いっぱい。
05/03/14 23:14:18おめでてぇなぁ
0027名無しさん@お腹いっぱい。
05/03/14 23:17:13資源があり余ってるのは一部の人だけでしょ。
現実にはGUIプログラムがwinよりも遅い、重いって感じてる人が多い筈だ。
0028名無しさん@お腹いっぱい。
05/03/14 23:18:400029名無しさん@お腹いっぱい。
05/03/14 23:23:06それならこの板にある全部のスレはUNIXってスレがあれば不要じゃん。
00303 == 5 == 7 == 10 なんだけど
05/03/14 23:25:05もう少し付き合ってやろう。
はっきりいって X ってのは、プロトコルの名前なのよ。
だから、X 自体は変えられない。
# 言い過ぎだってのはわかってるから突っ込むなよ > 分かってる連中
描画速度が Windows に負けてるとかって言うんだった
ら、それはおいらが書いた >>10 の後半部分以外の何者
でもないし、>>21 も書いてるように、DirectFB 系に走っ
たとしてもアドバンテージ的にはほとんど何もない。
で、どのあたりが実際に不満なんだ?
そこをちゃんと持ち出さないと、>>23 のスレでやった
方がいいってことになると思うが。
0031名無しさん@お腹いっぱい。
05/03/14 23:26:540032名無しさん@お腹いっぱい。
05/03/14 23:29:02そうかなあ。
俺、いまだに Pentium III 400MHz で X 使ってるけど、
全然遅いと思わないよ。メモリは512MB載っけてるけど。
同じマシンで Windows 2000 を使うと、立ち上がりから
なにから、遅くてかなわん。
遅いって感じてる人は、Xサーバのアクセラレーション
が効かないビデオカードか表示モードを使っている場合が
ほとんどだと思う。これは、クライアント・サーバーモデル
の問題じゃなくて、純粋にデバイスドライバの作りの問題
なので、混同しない方がいい。
うちの ThinkPad X24 の場合、32bpp だと確かに遅いけど
16bpp だと全然問題ない。描画の様子を見ると、明らかに
アクセラレーションの効き方が違ってる。
0033名無しさん@お腹いっぱい。
05/03/14 23:35:46X 上で動かすのと速度的にそんなにかわらない気がするんだけども。
というか、その手のツールキット自身がWindows のUI の再実装みたいなものなんだし、
上被せタイプである点/後追いな分性能に遅れをとってるとこもあるだろうさ。
重いのはX 自身よりも、gtk なりQt なり、アプリなりの作りの問題なんじゃ、ないかなぁ。
まったくの勘でしかないけれども。
0034名無しさん@お腹いっぱい。
05/03/14 23:36:38という感じだけど、これについてはX11以外に原因がありそうな気がする。
0035名無しさん@お腹いっぱい。
05/03/14 23:40:19激しく同意。Xlibの解説書がHP作りの入門書並に書店に溢れれば問題は解決。
誰か書いてくれ。
0036名無しさん@お腹いっぱい。
05/03/14 23:42:36http://freedesktop.org/Software/xcb
0037名無しさん@お腹いっぱい。
05/03/14 23:43:09言い出しっぺ(ry
0038名無しさん@お腹いっぱい。
05/03/14 23:43:26MozillaもNautilusも最初から統合環境を目指したアプリなんだよな。
ソースツリーの構造が複雑過ぎて訳分からね。
0039名無しさん@お腹いっぱい。
05/03/14 23:44:13原稿貯まらね〜w
0040名無しさん@お腹いっぱい。
05/03/14 23:47:04アクセラレーションの効かない fb サーバは確かに重いけど。
# ここ数年のマトモなビデオカードで 2D 性能は体感できるほど変わらんよ。
0041名無しさん@お腹いっぱい。
05/03/14 23:47:09という話がsylpheed-gtk2か何かであったような。
0042名無しさん@お腹いっぱい。
05/03/14 23:49:1500433 == 5 == 7 == 10 なんだけど
05/03/14 23:51:51そりゃ重くなるさ。
がんがれ >>35
0044名無しさん@お腹いっぱい。
05/03/14 23:57:460045名無しさん@お腹いっぱい。
05/03/15 00:06:06アプリ側で使う必要ないんとちゃう?
tool-kit の側で頑張るべき問題やろし...
0046名無しさん@お腹いっぱい。
05/03/15 01:11:33http://www.nat.org/2005/february/#9-February-2005
0047名無しさん@お腹いっぱい。
05/03/15 01:21:47最新の普及版程度のスペックをほいほい買えるようになったら、そう感じるようになった。
0048名無しさん@お腹いっぱい。
05/03/15 08:26:14|そんな機能をつけるよりもより軽く、より高速な物として欲しい。
m9
004916=40
05/03/15 11:13:54一理あるよね。
現状の X アプリではクラサバ構成でも問題ないけど。
0050名無しさん@お腹いっぱい。
05/03/15 11:18:09具体的には、サーバとクライアント間で通信されるデータをよりマクロにしてほしい。
できれば、かつての Display Postscript の復活きぼんぬ。
Microsoft の Avalon でもいいや。
パフォーマンスを出したいときのために、DRIみたいな仕組みももちろん
残しておいてほしいけど。
0051名無しさん@お腹いっぱい。
05/03/15 11:34:14まあ、アレは68020なのにそんなことしたのがいけないのかもしれないが。
0052名無しさん@お腹いっぱい。
05/03/15 12:11:240053名無しさん@お腹いっぱい。
05/03/15 13:10:46> 現状の X アプリではクラサバ構成でも問題ないけど。
client/server 捨てる必要性があるのか?
>>10とか >>21 がいってることがほとんど全てだぞ.
extension 作って local なレンダラにたいしては, 直接 GPU
操作でも何でもすりゃいいじゃねぇの.
俺は, 同じソフトが, 重くはなるがネットワーク透過に動いて
くれる方がさらにうれしいんだが.
>>51
> まあ、アレは68020なのにそんなことしたのがいけないのかもしれないが。
結局, PS プリンタは全て RISC に移行したわけだが...
>>52
きっと DPS の二の舞.
005416=40=49
05/03/15 17:53:45>client/server 捨てる必要性があるのか?
うん、クラサバを捨てるって考え方もあると思う。
X サーバとなる機械と X クライアントを実行する機械が、別経路で
通信できれば、無理して X のサバクラ上で動かす必要はないわけだし。
>俺は, 同じソフトが, 重くはなるがネットワーク透過に動いて
>くれる方がさらにうれしいんだが.
回線速度がなぁ。 GbE でもデカいテクスチャ送ると結構遅くなるし。
相当重くなりそう。
具体的に言うと、たとえば現状のアプリ、 GbE 経由でも gimp なんかは、
ちょっとだけ重いよね。なら gimp をローカルで動かしてファイル共有した方が
スムーズでいいじゃんって話。
# 念のため。アホみたいにリッチな描画になること前提のハナシっすよ。
# そんな描画ができて何がうれしいの? ってハナシもあるけど(w
0055名無しさん@お腹いっぱい。
05/03/15 18:11:48> 通信できれば、無理して X のサバクラ上で動かす必要はないわけだし。
意味がわかんないな。
リモートのプログラムを手元で動かすのに、
そのプログラムが X プロトコルなんか使わずに
わざわざ手元のハードウェア(ビデオ)をごりごり自前で動かすってこと?
0056名無しさん@お腹いっぱい。
05/03/15 18:37:0454は意味不明にもほどがあるな。
別経路だろうがなんだろうが、通信したら、結局クライアント・
サーバ方式じゃないか。
テクスチャの話もgimpの話も、現在のXのままでも、ローカルで
走らせれば解決する話にすぎなくて、クライアント・サーバー
モデルを捨てる必要があるという理由になってないじゃん。
だめだめ。
0057名無しさん@お腹いっぱい。
05/03/15 18:55:30通信しないってことで
アプリがローカルのハードウェア叩くのは悪夢だよ。
0058名無しさん@お腹いっぱい。
05/03/15 19:16:30> X サーバとなる機械と X クライアントを実行する機械が、別経路で通信できれば
やってるじゃん, SHM とか使って. この場合, 同一マ
シンマシンじゃないと動作しないわけだが...
X がとろいのは GPU のレンダリングパイプを有効に使
えていないからってのはわかってる?
X 以外の何持ってきても, GPU のレンダリングパイプを
有効に使えない限りは描画性能は似たり寄ったりにしか
ならない.
0059名無しさん@お腹いっぱい。
05/03/15 19:21:03用のエクステンションを開発するのが解で、サーバ
クライアントモデルを捨てるとかどうだとかいうの
は的外れもいいとこ。
0060名無しさん@お腹いっぱい。
05/03/15 19:39:36> アプリがローカルのハードウェア叩くのは悪夢だよ。
だからって, いまさらその昔の SunView のように, レ
ンダラ回りまで kernel に抱え込みたくはないわな.
# MS はやってるみたいだけど...
0061名無しさん@お腹いっぱい。
05/03/15 19:41:500062名無しさん@お腹いっぱい。
05/03/15 19:44:49削除されるほどかな。
レベルの低い議論は削除ってこと?
0063名無しさん@お腹いっぱい。
05/03/15 19:52:53俺は別に削除されてもいいよ。
1や54も早く忘れたいって思ってるんじゃないの?
0064名無しさん@お腹いっぱい。
05/03/15 20:44:17nvidia-driver入れてもfirefoxとかgimpのパフォーマンスはwindows>>>FreeBSDだったよ。
0065名無しさん@お腹いっぱい。
05/03/15 21:01:33のコア部分以外の問題に問題があると思うぞ。
そういうおおざっぱな比較じゃなくて、ちゃんとWindows
版とX11版でプロファイルとって、ボトルネックを計測
してから意見書けよ。
それに、nvidia が X11 版で Windows 版と同程度の
最適化を施してると思ってるの? そんなわけないだろ。
0066名無しさん@お腹いっぱい。
05/03/15 22:13:19重複してるとは思わんがなぁ.
実質, ■■■X11不要論■■■R2■■■ は, 不平不満を
並べてるだけのスレだし...
各論あっても, ええんちゃうの?
# つか, クソスレ乱立をも許容するのがウニ板.
# じゃなきゃこれだけクソスレ乱立してねぇだろうがよ.
00673 == 5 == 7 == 10 なんだけど
05/03/15 22:17:43> それに、nvidia が X11 版で Windows 版と同程度の
> 最適化を施してると思ってるの?
DRI 辺りの仕様が貧弱すぎです。
今の仕様は、一昔前のレンダリングパイプの仕様だもん。
0068名無しさん@お腹いっぱい。
05/03/15 22:24:47DRIに関しては全く同感。てゆうか、あれは一昔前以前
のような。でも、だからといって、クライアントサーバー
モデルを捨てる必要があるかっていうと、全然そんなことない。
それに、firefox や gimp 程度で、レンダリングパイプ
の活用度が関係してくるとも思わん。関係してくるのは、
今時のゲームアプリぐらいの負荷がかかった場合くらい
でしょ。
>>66
このスレも見当違いの不満を並べてるだけに見えるけど
なあ。どっちも似たようなもの。タイトル自身が見当
はずれな分だけ、このスレの方が不利な気がする。
誰かが、このスレの内容を不要論の方にコピペするなら、
このスレは要らん気が…
> # じゃなきゃこれだけクソスレ乱立してねぇだろうがよ.
まあ、これ以下のクソスレが乱立してるから、これくらい
許容範囲だって点には、同感。
■ このスレッドは過去ログ倉庫に格納されています