トップページ⇒unix
152コメント56KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。05/03/13 21:45:09
俺は無いと思う。
そんな機能をつけるよりもより軽く、より高速な物として欲しい。
0002名無しさん＠お腹いっぱい。05/03/13 21:48:42
XCloseDisplay(>>1);
0003名無しさん＠お腹いっぱい。05/03/13 21:50:51
はいぃ？
バックエンドのスパコンの出力を可視化するのはどうやればいいんだ？
0004名無しさん＠お腹いっぱい。05/03/13 21:52:05
>>3
なんでそんなスペシャルケースを持ってくるんだ？
0005名無しさん＠お腹いっぱい。05/03/13 21:54:00
それがおいらの仕事だからぁ。
0006名無しさん＠お腹いっぱい。05/03/13 21:55:47
そういう特別な物には特別に作ればいいんだよ。
スパコンからデスクトップまでをカバーする必要なんてまったく無い。
0007名無しさん＠お腹いっぱい。05/03/13 21:58:12
じゃぁ、X すてて別のものつくりゃいいじゃん。
0008名無しさん＠お腹いっぱい。05/03/13 22:01:04
>>7
何で誰も作らないの？
0009名無しさん＠お腹いっぱい。05/03/13 22:05:07
>>1
どっかそこらへんのスレと重複。以降はそちらへ。
0010名無しさん＠お腹いっぱい。05/03/13 22:15:49
>>8
X protocol 自体トランスポートは選ばないから、それなりの
extension 定義してやれば server/client モデルって部分も
隠蔽できるはず。ある意味 DRI がいい例だ。

問題なのは GPU を作っているメーカが、GPU の仕様を公表し
ないことだと思う。何かしたくても、「GPU つつけないから
DRI がいつまでたっても早くならない。」ってのが、現状だ
と思うけど。
0011名無しさん＠お腹いっぱい。05/03/13 22:23:06
X window system
http://pc5.2ch.net/test/read.cgi/unix/1023264974/
0012名無しさん＠お腹いっぱい。05/03/13 22:48:46
Client/Serverはあまりに古い。
これからはAgentモデルだな。
0013名無しさん＠お腹いっぱい。05/03/14 02:23:29
おぃおぃ。agent って、この文脈だと server と同じ意味よ。
0014名無しさん＠お腹いっぱい。05/03/14 02:29:14
Windowsと比べてマウスの動きがもっさりしてる。
0015名無しさん＠お腹いっぱい。05/03/14 05:02:21
>>14
そういうあなたに xset m ほげほげ
0016名無しさん＠お腹いっぱい。05/03/14 10:43:24
えー、クラサバ便利だけどなぁ。
あちこちから ssh に乗せて X のウィンドウ飛ばさない?
0017名無しさん＠お腹いっぱい。05/03/14 12:51:16
VNC!VNC!
0018名無しさん＠お腹いっぱい。05/03/14 13:02:11
vnc も vncserver が Xserver の役割をしてるから
軽快に動くんだけど
0019名無しさん＠お腹いっぱい。05/03/14 16:26:51
>>16
飛ばす飛ばす。
東京にしかライセンスがないソフトを大阪から使ったり。(w
0020名無しさん＠お腹いっぱい。05/03/14 16:40:00
たぶん>1が言いたいのは、
ご家庭のWinをリプレイスするようなスタンドアロンのデスクトップ端末としてのUNIXの登場で、
その時はXってシステムは冗長だから、もっと低レベルで動く軽いWindowSystemが欲しい。
ってことなんじゃないかなと推測。

まあ言いたい事も解らなくもない。
0021名無しさん＠お腹いっぱい。05/03/14 18:38:55
DirectFBとかの方向かな。
これも結局>>10がいう通りの理由で、パフォーマンスではXに対する優位性はない。

QtとかGTKがそこそこ使えるようになってきた昨今、大抵の事はXを直でさわる事なしに
出来ると思うけど。
0022名無しさん＠お腹いっぱい。05/03/14 18:44:54
windowsがほぼX端末になってるので困ります。
0023名無しさん＠お腹いっぱい。05/03/14 19:11:18
重複。以降はこちらへ。

■■■Ｘ１１不要論■■■Ｒ２■■■
http://pc5.2ch.net/test/read.cgi/unix/1099755829/
0024名無しさん＠お腹いっぱい。05/03/14 22:50:41
>>20
その通りです。言葉足らずでした。
>>23
そのスレはCUI or GUI的なスレだと思うので、重複ではないと思います。
0025名無しさん＠お腹いっぱい。05/03/14 23:08:14
>>24

>>10が書いているように、別にXだからって、必ずしも
クライアント・サーバモデルのオーバヘッドがかかる
わけではない。(実際、XでもDRIを使えば、クライアントが
直接描画できる。)
あと、もはやCPUもメモリもあり余ってるんだから、いまさら
クライアント・サーバモデル程度では、まったく負荷的問題
にならない筈。

それどころか、今後はどうも単一CPUで複数の仮想マシンを
運用するような流れになりそうなので(IntelのVanderpool
Technologyとか)、複数の仮想マシンを単一のコンソールから
利用できるX的な作りの方を、時代が必要といるような。
Windows的なやり方だと、ウィンドウ単位ではなくてスクリーン
単位で切り替える必要があるので、とっても不便。
0026名無しさん＠お腹いっぱい。05/03/14 23:14:18
え〜〜〜っと、SUNView復活しる！ってことか？
おめでてぇなぁ
0027名無しさん＠お腹いっぱい。05/03/14 23:17:13
>>25
資源があり余ってるのは一部の人だけでしょ。
現実にはGUIプログラムがwinよりも遅い、重いって感じてる人が多い筈だ。
0028名無しさん＠お腹いっぱい。05/03/14 23:18:40
>>11 でいいじゃん。
0029名無しさん＠お腹いっぱい。05/03/14 23:23:06
>>28
それならこの板にある全部のスレはUNIXってスレがあれば不要じゃん。
00303 == 5 == 7 == 10 なんだけど05/03/14 23:25:05
>>24
もう少し付き合ってやろう。
はっきりいって X ってのは、プロトコルの名前なのよ。
だから、X 自体は変えられない。

# 言い過ぎだってのはわかってるから突っ込むなよ > 分かってる連中

描画速度が Windows に負けてるとかって言うんだった
ら、それはおいらが書いた >>10 の後半部分以外の何者
でもないし、>>21 も書いてるように、DirectFB 系に走っ
たとしてもアドバンテージ的にはほとんど何もない。

で、どのあたりが実際に不満なんだ？

そこをちゃんと持ち出さないと、>>23 のスレでやった
方がいいってことになると思うが。
0031名無しさん＠お腹いっぱい。05/03/14 23:26:54
春厨が必死に伸ばす
0032名無しさん＠お腹いっぱい。05/03/14 23:29:02
>>27
そうかなあ。
俺、いまだに Pentium III 400MHz で X 使ってるけど、
全然遅いと思わないよ。メモリは512MB載っけてるけど。
同じマシンで Windows 2000 を使うと、立ち上がりから
なにから、遅くてかなわん。

遅いって感じてる人は、Xサーバのアクセラレーション
が効かないビデオカードか表示モードを使っている場合が
ほとんどだと思う。これは、クライアント・サーバーモデル
の問題じゃなくて、純粋にデバイスドライバの作りの問題
なので、混同しない方がいい。
うちの ThinkPad X24 の場合、32bpp だと確かに遅いけど
16bpp だと全然問題ない。描画の様子を見ると、明らかに
アクセラレーションの効き方が違ってる。
0033名無しさん＠お腹いっぱい。05/03/14 23:35:46
gtk とかQt をWindows上にネイティブに実装してみても、
X 上で動かすのと速度的にそんなにかわらない気がするんだけども。
というか、その手のツールキット自身がWindows のUI の再実装みたいなものなんだし、
上被せタイプである点／後追いな分性能に遅れをとってるとこもあるだろうさ。
重いのはX 自身よりも、gtk なりQt なり、アプリなりの作りの問題なんじゃ、ないかなぁ。
まったくの勘でしかないけれども。
0034名無しさん＠お腹いっぱい。05/03/14 23:36:38
Mozilla(Seamonkey, Firefoxとも)のパフォーマンスはWindows＞＞＞＞Linux
という感じだけど、これについてはX11以外に原因がありそうな気がする。
0035名無しさん＠お腹いっぱい。05/03/14 23:40:19
>重いのはX 自身よりも、gtk なりQt なり、アプリなりの作りの問題なんじゃ
激しく同意。Xlibの解説書がHP作りの入門書並に書店に溢れれば問題は解決。
誰か書いてくれ。
0036名無しさん＠お腹いっぱい。05/03/14 23:42:36
XCB/XCL
http://freedesktop.org/Software/xcb
0037名無しさん＠お腹いっぱい。05/03/14 23:43:09
>>35
言い出しっぺ(ry
0038名無しさん＠お腹いっぱい。05/03/14 23:43:26
>これについてはX11以外に原因がありそうな気がする。
MozillaもNautilusも最初から統合環境を目指したアプリなんだよな。
ソースツリーの構造が複雑過ぎて訳分からね。
0039名無しさん＠お腹いっぱい。05/03/14 23:44:13
>言い出しっぺ(ry
原稿貯まらね〜ｗ
0040名無しさん＠お腹いっぱい。05/03/14 23:47:04
描画が遅いんじゃなくてデスクトップ環境が重かったりするんじゃないの?

アクセラレーションの効かない fb サーバは確かに重いけど。

# ここ数年のマトモなビデオカードで 2D 性能は体感できるほど変わらんよ。
0041名無しさん＠お腹いっぱい。05/03/14 23:47:09
gtk2はdeprecatedなwidgetを新しいものに置き換えたらベラボーに遅くなった
という話がsylpheed-gtk2か何かであったような。
0042名無しさん＠お腹いっぱい。05/03/14 23:49:15
犬厨が必死に伸ばす
00433 == 5 == 7 == 10 なんだけど05/03/14 23:51:51
>>41
そりゃ重くなるさ。
がんがれ >>35
0044名無しさん＠お腹いっぱい。05/03/14 23:57:46
正直もう生の Xlib は使いたくないなあ。
0045名無しさん＠お腹いっぱい。05/03/15 00:06:06
>>44
アプリ側で使う必要ないんとちゃう?
tool-kit の側で頑張るべき問題やろし...
0046名無しさん＠お腹いっぱい。05/03/15 01:11:33
そういえば少し前にXGLの話題で盛り上がっていたのを思い出した。
http://www.nat.org/2005/february/#9-February-2005
0047名無しさん＠お腹いっぱい。05/03/15 01:21:47
計算機の資源の少なさで困るのは一部の貧乏人と遺産を有効活用してる人だけ。
最新の普及版程度のスペックをほいほい買えるようになったら、そう感じるようになった。
0048名無しさん＠お腹いっぱい。05/03/15 08:26:14
>>1
|そんな機能をつけるよりもより軽く、より高速な物として欲しい。
m9
004916=4005/03/15 11:13:54
しかし将来、本当にリッチな描画にしたいとかなら 1 の言うことにも
一理あるよね。
現状の X アプリではクラサバ構成でも問題ないけど。
0050名無しさん＠お腹いっぱい。05/03/15 11:18:09
逆に漏れはもっと分離してほしい。
具体的には、サーバとクライアント間で通信されるデータをよりマクロにしてほしい。
できれば、かつての Display Postscript の復活きぼんぬ。
Microsoft の Avalon でもいいや。

パフォーマンスを出したいときのために、DRIみたいな仕組みももちろん
残しておいてほしいけど。
0051名無しさん＠お腹いっぱい。05/03/15 11:34:14
さすがにもうDPSは勘弁してほしいな。
まあ、アレは68020なのにそんなことしたのがいけないのかもしれないが。
0052名無しさん＠お腹いっぱい。05/03/15 12:11:24
OS X の display pdf ってどうなの？
0053名無しさん＠お腹いっぱい。05/03/15 13:10:46
>>49
> 現状の X アプリではクラサバ構成でも問題ないけど。

client/server 捨てる必要性があるのか?
>>10とか >>21 がいってることがほとんど全てだぞ.

extension 作って local なレンダラにたいしては, 直接 GPU
操作でも何でもすりゃいいじゃねぇの.
俺は, 同じソフトが, 重くはなるがネットワーク透過に動いて
くれる方がさらにうれしいんだが.

>>51
> まあ、アレは68020なのにそんなことしたのがいけないのかもしれないが。
結局, PS プリンタは全て RISC に移行したわけだが...

>>52
きっと DPS の二の舞.
005416=40=4905/03/15 17:53:45
>>53

>client/server 捨てる必要性があるのか?

うん、クラサバを捨てるって考え方もあると思う。

X サーバとなる機械と X クライアントを実行する機械が、別経路で
通信できれば、無理して X のサバクラ上で動かす必要はないわけだし。


>俺は, 同じソフトが, 重くはなるがネットワーク透過に動いて
>くれる方がさらにうれしいんだが.

回線速度がなぁ。 GbE でもデカいテクスチャ送ると結構遅くなるし。
相当重くなりそう。

具体的に言うと、たとえば現状のアプリ、 GbE 経由でも gimp なんかは、
ちょっとだけ重いよね。なら gimp をローカルで動かしてファイル共有した方が
スムーズでいいじゃんって話。

# 念のため。アホみたいにリッチな描画になること前提のハナシっすよ。
# そんな描画ができて何がうれしいの? ってハナシもあるけど(w
0055名無しさん＠お腹いっぱい。05/03/15 18:11:48
> X サーバとなる機械と X クライアントを実行する機械が、別経路で
> 通信できれば、無理して X のサバクラ上で動かす必要はないわけだし。

意味がわかんないな。
リモートのプログラムを手元で動かすのに、
そのプログラムが X プロトコルなんか使わずに
わざわざ手元のハードウェア(ビデオ)をごりごり自前で動かすってこと？
0056名無しさん＠お腹いっぱい。05/03/15 18:37:04
> 意味がわかんないな。

54は意味不明にもほどがあるな。
別経路だろうがなんだろうが、通信したら、結局クライアント・
サーバ方式じゃないか。

テクスチャの話もgimpの話も、現在のXのままでも、ローカルで
走らせれば解決する話にすぎなくて、クライアント・サーバー
モデルを捨てる必要があるという理由になってないじゃん。
だめだめ。
0057名無しさん＠お腹いっぱい。05/03/15 18:55:30
捨てなくても効率をあげるためにXのプロトコルを見直そうってことでいいんじゃない？

通信しないってことで
アプリがローカルのハードウェア叩くのは悪夢だよ。

0058名無しさん＠お腹いっぱい。05/03/15 19:16:30
>>54
> X サーバとなる機械と X クライアントを実行する機械が、別経路で通信できれば

やってるじゃん, SHM とか使って. この場合, 同一マ
シンマシンじゃないと動作しないわけだが...

X がとろいのは GPU のレンダリングパイプを有効に使
えていないからってのはわかってる?

X 以外の何持ってきても, GPU のレンダリングパイプを
有効に使えない限りは描画性能は似たり寄ったりにしか
ならない.
0059名無しさん＠お腹いっぱい。05/03/15 19:21:03
で、GPUのレンダリング能力を活用するのには、それ
用のエクステンションを開発するのが解で、サーバ
クライアントモデルを捨てるとかどうだとかいうの
は的外れもいいとこ。
0060名無しさん＠お腹いっぱい。05/03/15 19:39:36
>>57
> アプリがローカルのハードウェア叩くのは悪夢だよ。
だからって, いまさらその昔の SunView のように, レ
ンダラ回りまで kernel に抱え込みたくはないわな.
# MS はやってるみたいだけど...
0061名無しさん＠お腹いっぱい。05/03/15 19:41:50
このスレには削除依頼が出ているので書き込まないで下さい。
0062名無しさん＠お腹いっぱい。05/03/15 19:44:49
ネタスレですらないバカスレだとは思うけど、
削除されるほどかな。
レベルの低い議論は削除ってこと？
0063名無しさん＠お腹いっぱい。05/03/15 19:52:53
まあ重複だってことなんじゃないの？
俺は別に削除されてもいいよ。
1や54も早く忘れたいって思ってるんじゃないの？
0064名無しさん＠お腹いっぱい。05/03/15 20:44:17
ドライバが悪いとか言ってもさ、
nvidia-driver入れてもfirefoxとかgimpのパフォーマンスはwindows>>>FreeBSDだったよ。
0065名無しさん＠お腹いっぱい。05/03/15 21:01:33
gimp や firefox の動作速度は、ウィンドウシステム
のコア部分以外の問題に問題があると思うぞ。
そういうおおざっぱな比較じゃなくて、ちゃんとWindows
版とX11版でプロファイルとって、ボトルネックを計測
してから意見書けよ。

それに、nvidia が X11 版で Windows 版と同程度の
最適化を施してると思ってるの？ そんなわけないだろ。
0066名無しさん＠お腹いっぱい。05/03/15 22:13:19
>>61
重複してるとは思わんがなぁ.
実質, ■■■Ｘ１１不要論■■■Ｒ２■■■ は, 不平不満を
並べてるだけのスレだし...
各論あっても, ええんちゃうの?
# つか, クソスレ乱立をも許容するのがウニ板.
# じゃなきゃこれだけクソスレ乱立してねぇだろうがよ.
00673 == 5 == 7 == 10 なんだけど05/03/15 22:17:43
>>65
> それに、nvidia が X11 版で Windows 版と同程度の
> 最適化を施してると思ってるの？

DRI 辺りの仕様が貧弱すぎです。
今の仕様は、一昔前のレンダリングパイプの仕様だもん。
0068名無しさん＠お腹いっぱい。05/03/15 22:24:47
>>67
DRIに関しては全く同感。てゆうか、あれは一昔前以前
のような。でも、だからといって、クライアントサーバー
モデルを捨てる必要があるかっていうと、全然そんなことない。

それに、firefox や gimp 程度で、レンダリングパイプ
の活用度が関係してくるとも思わん。関係してくるのは、
今時のゲームアプリぐらいの負荷がかかった場合くらい
でしょ。

>>66
このスレも見当違いの不満を並べてるだけに見えるけど
なあ。どっちも似たようなもの。タイトル自身が見当
はずれな分だけ、このスレの方が不利な気がする。
誰かが、このスレの内容を不要論の方にコピペするなら、
このスレは要らん気が…

> # じゃなきゃこれだけクソスレ乱立してねぇだろうがよ.

まあ、これ以下のクソスレが乱立してるから、これくらい
許容範囲だって点には、同感。
0069名無しさん＠お腹いっぱい。05/03/15 22:36:05
重複してると思います。重複しています。
0070名無しさん＠お腹いっぱい。05/03/15 22:37:56
>>69
だから, ウニ板にどれだけ重複スレがあるよ.
「彼女」系の数だけでも...
0071名無しさん＠お腹いっぱい。05/03/15 22:41:53
タイトルミスったね・・・ｗ
でも出来れば折角だし今後のX-Window-Systemがどうあるべきか？とかを語って欲しいな。

Xで動くアプリは結構手が入ってるけど、その根本のX自体は余り手が入ってないじゃん。
0072名無しさん＠お腹いっぱい。05/03/15 22:43:46
「ボクが立てたスレを盛り上げるんだ！きっと職人さんも来てくれる〜」のAA希望
0073名無しさん＠お腹いっぱい。05/03/15 22:46:07
>>72
だってそうじゃない？
このタイトルではもう無理だし、でも折角スレあるんだし、
人も結構いるんだし、何かの議論の場となるならそっちの方がいいじゃない。
0074名無しさん＠お腹いっぱい。05/03/15 22:49:12
>>68
> 誰かが、このスレの内容を不要論の方にコピペするなら、
> このスレは要らん気が…
する気はない.

つか, このペースで続けば, 今の X の問題点を洗い出
すには, ちょうどいい話の流れになってると思うが?

手頃に何も考えてないアフォが何人か混じってるみたい
だし..
0075名無しさん＠お腹いっぱい。05/03/15 22:59:43
og(ry
007616=40=49=5405/03/15 23:29:05
うひ、なんかえらい叩かれてるな(w

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


要するに >>56 の

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

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

# 念のため、パフォーマンスを求める場合だよ。
# DRI レベルの話じゃない。今更 2D なんて、どーでもいいっしょ。
# あと今の X から無くせって言ってるわけでもない。
# 現に今も飛ばしたウィンドウから書き込んでるし。
007716=40=49=54=7605/03/15 23:29:50
すまん、しつこいね。これ最後。

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

# GPU だけじゃなく CPU プログラムもサーバに転送できれば毎フレーム描画も
# 可能だよね。って、それって結局ローカルで動かしてるだけじゃん。みたいにならん?
0078名無しさん＠お腹いっぱい。05/03/15 23:38:31
>>76
> って話。ローカルで走らせることで解決する話なら、 X の
> クラサバモデル無くてもいいじゃん? ってコト。

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

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

へ? DRI って GL を高速描画するために考えられた
メカニズムだったはずなんだが.
0079名無しさん＠お腹いっぱい。05/03/15 23:39:13
>>76
DRIは2Dでは使っていないのだが、何か根本的な部分で勘違いしていないか?
0080名無しさん＠お腹いっぱい。05/03/15 23:41:38
>Xで動くアプリは結構手が入ってるけど
アプリに手なんか余り入ってないと思うのは僕だけ？
0081名無しさん＠お腹いっぱい。05/03/15 23:43:28
> って話。ローカルで走らせることで解決する話なら、 X の
> クラサバモデル無くてもいいじゃん? ってコト。

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

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

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

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

そういう場合でも、ちゃんとボトルネックがどこにあるか計測して
からやるのが当然だろ。単なる思いつきでクラサバやめればぁ？
なんて言ってるのは、エンジニアリング以前。
008216=40=49=54=76=7705/03/15 23:50:36
スマソ、 DRI に関してはミスった。

firefox とか gimp の話題にからまってたから矩形転送回りかと思ったのよ。
これは思い込みもあったし。

はずかすぃ。。。

# 顔真っ赤だよ(w
0083名無しさん＠お腹いっぱい。05/03/15 23:51:11
>>76-81
自演？
0084名無しさん＠お腹いっぱい。05/03/15 23:53:49
>>83
ヴァ〜レ〜タ〜カ〜
008516=40=49=54=76=77=8205/03/15 23:54:39
>>81

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

それはわかってるのよ。 X のクラサバじゃなくて他の方法もあるでしょ。
って話をしてるつもりなんだけど。

この場合ファイル共有の方があきらかに効率良いでしょ。

# もちろん、ファイル共有だけじゃ済まないケースもあるけど。
0086名無しさん＠お腹いっぱい。05/03/15 23:56:58
> この場合ファイル共有の方があきらかに効率良いでしょ。

で、何が言いたいの？ ファイル共有を使いたければ使えば
いいじゃん。その場合、ウィンドウシステムは現在のままで
何も変える必要がないことになるが。

矩形転送なら DRI じゃなくて MIT-SHM エクステンション。
gimp あたりなら、既にこれは使ってる気がする。
それに、firefox はそういう問題じゃないだろ、明らかに。

とにかく実際になにが起きているのか計測せずに、勝手に
妄想しているだけでは無意味。
0087名無しさん＠お腹いっぱい。05/03/16 00:01:58
クライアント/サーバーモデルは兎も角、
ATOMとPROPERTYに関しては別鯖立てても良くない？
0088名無しさん＠お腹いっぱい。05/03/16 00:06:38
なんでそうする必要があるの？
今なんとかした方がいいのは、いまどきのGPUに対応した
描画プリミティブの改善と、ローカルな場合に、テクスチャ
などの資源を効率良くGPUに送り込む方法(どちらも、
Xのエクステンションの追加で行うべき話) であって、ATOM
やPROPERTYなんて今のままでも全然問題ないと思うけど。
00893 == 5 == 7 == 10 なんだけど 05/03/16 00:07:14
>>82
> firefox とか gimp の話題にからまってたから矩形転送回りかと思ったのよ。
> これは思い込みもあったし。

今時、それなりのネットワーク帯域と高速なレンダリング
パイプ持ってれば、2D でしこしこ書くより 3D で書いて、
ビューモデルを 2D にマップした方が早いって知ってる？
00903 == 5 == 7 == 10 なんだけど 05/03/16 00:10:14
ごめん。
89> マップした方が早いって知ってる？
「速い」だよね。
0091名無しさん＠お腹いっぱい。05/03/16 00:30:29
>>88
で, 元の X protocol は extension の決定と, 描画領域を含むウィ
ンドーの map/unmap だけを行うと...
それはそれで気持がいいな.
009216=40=49=54=76=77=82=8505/03/16 00:41:33

>>89
あぁ、ネットワークで帯域足りる環境もあるのかぁ。

いや、実はこの一連の妄想って毎フレーム更新するくらいの GL 環境を
考えてたのよ。で、問題になるのがネットワーク経由のウィンドウ
飛ばしかな、と。
(鯖の GPU/CPU のアーキテクチャは? とか、そんなデータ送れんの? とか、
結局鯖にプログラム送ったらローカルと変わらんじゃん? とか。)

でも、よくよく考えてみれば X みたいにウィンドウ飛ばさなくても
昔からある portforward なりファイル共有なりで、実は大半の目的は
達成できるんじゃないかって思ったわけ。

なら、 X のクラサバ捨ててもいいんじゃん? って思ったって感じ。


>>86

ってことを言いたかったんだけど、まぁ、前提が妄想だからなぁ。
もっと >>49 で妄想を強調すべきだったね。すまんね。
0093名無しさん＠お腹いっぱい。05/03/16 00:48:12
>>92
> でも、よくよく考えてみれば X みたいにウィンドウ飛ばさなくても

ウィンドーは飛んでないぞ.
飛んでるのはウィンドーの管理リクエストと該当
ウィンドーに対する描画リクエスト.
まぁ, 実際には入力その他のイベントも飛ぶけどね.
0094名無しさん＠お腹いっぱい。05/03/16 13:22:16
>>70
今重複スレが多いことが
重複スレを増やしていいことの理由にはならんよ。
0095名無しさん＠お腹いっぱい。05/03/16 15:30:27
>>94
理由にならなかったら経済戦略の色々な技術が根拠を失うけどな。
気持ちは分かるし94を否定するつもりは無いが、
その情念は今は危険だ。
0096名無しさん＠お腹いっぱい。05/03/16 15:33:34
>>70
全部削除依頼出していいよ。
0097名無しさん＠お腹いっぱい。05/03/16 15:34:17
# rm -fr http://www.2ch.net/*

0098名無しさん＠お腹いっぱい。05/03/16 23:00:12
そのスレをすてるなんてとんでもない！
0099名無しさん＠お腹いっぱい。05/03/17 00:09:21
>>94,96
ウソスレと何とかはウニ板の花!!!
つか, クソじゃないスレが何割あるよ?
0100名無しさん＠お腹いっぱい。05/03/17 00:27:57
とりあえず 100 でも取ってみるか。
0101名無しさん＠お腹いっぱい。05/03/17 01:21:04
コンピュータやプログラムについてあんまり理解がないのだが、前々から
「なんでLinux(UNIX)のGUIプログラムは動作がWinに比べてモッサリしてるんだろ？」と
疑問を持ちつづけてきた。

自身の経験やこのスレも含めた諸々の情報を解釈するに、

・ハードのドライバがWinに比べて最適化されていないのは確かだが、それが上記モッサリの
　原因とはなりえない。　なぜなら、2D描画ごときタスクはハードウェアにとってさしたる負担
　ではなく、またドライバの出来が体感を左右する程影響することもない。　あくまで3Dの話。

・Xは大規模で複雑なソフトウェアである。最適化によって上記モッサリを改善する余地が
　あるかもしれない。が、クライアント?サーバな仕組みがその原因ではない。　よくあるクラ
　イアントとサーバが線で繋がれた図で見ると確かにボトルネックっぽく見えるが。

・GTK+,Qt 実はこれらXの上のライブラリが最大のボトルネックじゃなかろうか。
　体感速度向上の最適化はまだ本腰を入れて取り組まれていないようだ。　今後新しい
　コンパイラ gcc4.x とセットでモッサリ解消が進むのではと楽観的に期待している。

以上、素人のチラ裏でした。
0102名無しさん＠お腹いっぱい。05/03/17 01:55:44
そりゃ、Python+GTKとかで書けば遅いわな。
Mozillaは大差ないじゃん。
0103名無しさん＠お腹いっぱい。05/03/17 01:58:46
だいたい合ってるけど、細かいこと言い出すと

> ・ハードのドライバがWinに比べて最適化されていないのは確かだが、それ
> が上記モッサリの原因とはなりえない。

もしアクセラレーションがちゃんと効いてないと、
モッサリどころか、目茶目茶遅くなる場合もあるので注意。
>>32の32bppのケースとか。

> クライアント?サーバな仕組みがその原因ではない。

3D game みたいな応用の場合、Xプロトコルの機能不足が
原因であるケースもある。ただし、これについてもクライ
アント・サーバな仕組みを保ったままエクステンションの追加で
問題を解決することが可能。
0104名無しさん＠お腹いっぱい。05/03/17 11:45:46
サーバ・クライアント間の回線が細い場合はどうよ？
イベントが体感できるほど遅く届くとか、イメージの
転送に時間がかかるとか。
0105名無しさん＠お腹いっぱい。05/03/17 12:22:20
>>101

GTK の開発者間で最適化しようという流れになっているの ?
ボランティアベースのプロジェクトって, こういう曖昧な要求に対しては
動きが鈍いと思うんだけど.
あと, コンパイラを gcc 4.x にかえたからといって, 劇的に速くなるとは思えない.
結局, 3 年後も今と同じだと思う.
0106名無しさん＠お腹いっぱい。05/03/17 12:27:55
>>104
今話題になってるのは、そういう遅くなって当たり前の
話じゃなくて、ローカルで本来速いはずの動作がなぜか
遅いって話では？
0107名無しさん＠お腹いっぱい。05/03/17 14:02:56
そもそも windows の toolkit と比較するのが間違ってるんじゃないの。
0108名無しさん＠お腹いっぱい。05/03/17 17:00:53
そもそもtoolkitをウィンドウシステムと分離したのがX Window Systemの敗因

「それがいい」と言っている人がいる限り、UNIXは一般人の間には普及
しないんだろうなあ。
0109名無しさん＠お腹いっぱい。05/03/17 17:14:14
敗因って何に負けたの？
0110名無しさん＠お腹いっぱい。05/03/17 17:17:35
自民党にでも負けたんじゃない？
0111名無しさん＠お腹いっぱい。05/03/17 20:40:06
>>108
> toolkitをウィンドウシステムと分離
って, どうゆう意味よ?
0112名無しさん＠お腹いっぱい。05/03/17 21:01:33
toolkit 層をきちんと分離すると、効率が落ちるとでも
思ってるんじゃないの？ 阿呆すぎる。
0113名無しさん＠お腹いっぱい。05/03/17 21:23:15
遅いのを全てドライバのせい、メーカーのせいにしてても何も前に進みませんよ。
0114名無しさん＠お腹いっぱい。05/03/17 21:29:09
>>113
してないじゃん.
nVidia のドライバだって, Windows に比べると遅いし,
DRI の仕様にも問題があるって書いてあるじゃん.
0115名無しさん＠お腹いっぱい。05/03/17 21:31:02
>>114
それをドライバのせいって言うんじゃないの？
0116名無しさん＠お腹いっぱい。05/03/17 21:35:44
>>115
DRI の仕様がちゃんと最近のレンダリングパイプに
対応できていれば, nVidia だってもっと速いドラ
イバが作れてるはずだから, DRI の仕様を見直す必
要があるのでは?
と言う意味で, 言ってるんだが...
だれも, ドライバのせいにしてないと思うぞ.

# メーカが GPU の仕様を公開してくれないのは,
# また, 別の話.
0117名無しさん＠お腹いっぱい。05/03/17 21:41:05
DRIってショボいんだね・・・
Xの根幹技術がこんなんでよく
”UNIXなら古いPCでもサクサク動く”←UNIX好きの奴が良く言う台詞
なんて言葉が出てくるものだよ。
0118名無しさん＠お腹いっぱい。05/03/17 21:44:58
>>117
> ”UNIXなら古いPCでもサクサク動く”←UNIX好きの奴が良く言う台詞

それは、また別の文脈だろう…
少なくとも、スクリプト書いて処理できるレベルなら、 Unix の方が
効率よく処理できるのは事実なんだから。
0119名無しさん＠お腹いっぱい。05/03/17 21:50:49
> ”UNIXなら古いPCでもサクサク動く”←UNIX好きの奴が良く言う台詞

はつみみです。
0120名無しさん＠お腹いっぱい。05/03/17 22:30:52
> DRIってショボいんだね・・・
> Xの根幹技術がこんなんでよく

えええ、DRIをXの根幹技術だと思ってる君は何者？
% xdpyinfo | grep DRI
XFree86-DRI
名前を見るだけで分かる通り、最近になってXFree86
projectで付け加えたものですが、なにか？

あと、DRIがショボいんじゃなくて、GPUの利用方法が
最近変わりつつある(GPUがプログラマブルデバイスと
化してきている)ので、それに応じた別のエクステンション
が必要だってことなんだが。
これに関しては、金かけまくっているWindowsの方も、
まだ変化の途中に過ぎないだろ。
0121名無しさん＠お腹いっぱい。05/03/17 22:39:57
>>120

> あと、DRIがショボいんじゃなくて、GPUの利用方法が
> 最近変わりつつある(GPUがプログラマブルデバイスと
> 化してきている)ので、それに応じた別のエクステンション

うーん、わかんねーな。Ｘでフラグメントプログラム書くってこと？
0122名無しさん＠お腹いっぱい。05/03/17 23:02:38
うん、そゆこと。DRI の仕組みで書けたっけ？
0123名無しさん＠お腹いっぱい。05/03/17 23:20:21
しかし、これが firefox や gimp とは関係ないのは明白だな。
Win用の firefox や gimp だって、フラグメントプログラム
は使ってないのは間違いないからな。
それどころか DirectX 依存の処理だってやってないんじゃ
ないか。GDI の範囲内だけだろう。

結論: アプリかツールキットを直せ
0124名無しさん＠お腹いっぱい。05/03/17 23:29:16
gimp が遅いって人は
同じマシンの gimp for win ときちんと比較して行ってるの？
0125名無しさん＠お腹いっぱい。05/03/18 00:03:46
DiaとかSodipodiのWin版なら使ったことあるけど、普通に遅かったよ。
0126名無しさん＠お腹いっぱい。05/03/18 00:16:00
>>122

書けないことはないと思うが、フラグメントプログラムで
何をしたいのかが聞きたい。
0127名無しさん＠お腹いっぱい。05/03/18 00:24:10
Qt/KDEは最適化を意識する動きがあるからちょっと期待できる。
0128名無しさん＠お腹いっぱい。05/03/18 01:06:32
ここまでにもちらほら出てきてて気になってたんだけど,
X が遅いのは GPU をちゃんと使えてないからなの ?
>>123 でも出てるけど, gimp とか firefox とかでは関係ないのでは ?

それよりも, OpenOffice の GUI ってもっさりしてない ?
0129名無しさん＠お腹いっぱい。05/03/18 01:22:55
>>126
ﾁｮｰﾊﾞﾘﾊﾞﾘな3Dゲームとか?
0130名無しさん＠お腹いっぱい。05/03/18 01:26:32
>>128
> X が遅いのは GPU をちゃんと使えてないからなの ?
そこの切り分けすら、スレの中ではまだ何もやっていない。

> gimp とか firefox とかでは関係ないのでは ?
これに関しては、作ってる側が window system (バック
エンドは何でもいい)の、責任にしてしまってる部分が
多々あった(最近の状況は知らない)ので、いっしょくたに
話されている部分もある、と思う。
0131名無しさん＠お腹いっぱい。05/03/18 01:27:12
> X が遅いのは GPU をちゃんと使えてないからなの ?

ちゃんと原因を追求しないで答を求めるのは意味ないだろ。
遅いにもいろいろあるから、原因だって複数あるだろ。
>>32のX24なんかは、ドライバが、アクセラレーション機能を
ちゃんと使えてないってだけの理由なんだし。

> それよりも, OpenOffice の GUI ってもっさりしてない ?

OpenOffice は想像を絶する巨大プログラムなので、ぜんぜん
最適化されてない。だいたいソースを展開するだけでディスク
を1GB、コンパイルするだけで4GBも必要とする単一アプリケー
ションなんて俺は初めて見たよ。
0132名無しさん＠お腹いっぱい。05/03/18 01:35:20
ソースが1GBもあるの？すげえ。
0133名無しさん＠お腹いっぱい。05/03/18 01:38:15
>>1 が何考えて立てたかわからんけど、
徐々に良スレ化してないか、このスレ？
0134名無しさん＠お腹いっぱい。05/03/18 01:45:32
比較的詳しい人をあおって雑談に参加させ、
読んでて飽きない程度の雑談を展開するレベルのネタスレだと思う。
0135名無しさん＠お腹いっぱい。05/03/18 01:49:24
>>134
それでもいいんだけどね.
少なくとも, X の現状のスナップショットにはなってるでしょ?
0136名無しさん＠お腹いっぱい。05/03/18 01:52:20
>>133-134
（　ﾟдﾟ） …
0137名無しさん＠お腹いっぱい。05/03/18 10:11:33
レンダリングパイプって言葉を使ってるやつが
ひっかきまわしてるだけだろ。
0138名無しさん＠お腹いっぱい。05/03/18 12:40:33
X、遅いか？
0139名無しさん＠お腹いっぱい。05/03/18 13:02:07
フォントをサーバ側とクライアント側のどっちが描画しているのかややこしくて、
freetype バックエンド(xttパッチ入り)と xft の違いが良くよからんです。

freetype バックエンドを使った場合は、Xサーバ側のフォントが使われて
xft を使った場合は、Xクライアント側のフォントが使われる

という解釈は正しいでつか？

漏れとしてはXクライアント側のフォントじゃなくて、Xサーバ側のフォントを常に
使わせるようにしたいんだけど、これは xorg.conf とかでなんとかなるもの？
それともどっちのフォントを使うかはアプリケーション依存？

fonts.dirだったり、fonts.confだったり、設定ファイルがとにかくややこしすぎるよ。
歴史的経緯はどうでもいいから、なんとか統一できない？
0140名無しさん＠お腹いっぱい。05/03/18 13:34:05
スレ違い
0141名無しさん＠お腹いっぱい。05/03/18 14:49:07
体感速度を改善する、といったユーザビリティ関連のタスクはドキュメント整備と同様に
オープンソースでは二の次として後回しされ、まだうまく機能していない。

これを実現するためには、
■体感速度に不満を感じるケースを広くユーザから集め
■その原因を特定し
■根本的対策を施す。必要なら組織横断的にタスクフォースで。
といった枠組みが不可欠と思われる。

KDE,GNOMEなど統合デスクトップ環境ならすでにbugzillaがある程度上記機能を包括しているが
充分な力が入っているとは言い難い。
能力と権限を備えた特殊部隊が必要だろう。MSやAppleのように。
0142名無しさん＠お腹いっぱい。05/03/18 18:19:30
>必要なら組織横断的に
って下手したら著作権法違反で逮捕されるじゃん。
犯罪者と手を組む人なんているの？
0143名無しさん＠お腹いっぱい。05/03/18 18:24:14
>>142
おまえわかってないだろ。
0144名無しさん＠お腹いっぱい。05/03/19 07:19:39
一つ聞くけど、
このスレってLinux用のP2P作りたがってる人とか常駐してたよね？
あとMSの人とか。
0145名無しさん＠お腹いっぱい。05/03/19 11:08:06
>>144
> 一つ聞くけど、
いいですよ。

> このスレってLinux用のP2P作りたがってる人とか常駐してたよね？
いいえ。

> あとMSの人とか。
いいえ。
0146名無しさん＠お腹いっぱい。05/03/20 00:08:39
勘違いなのか。それは申し訳無い。
0147名無しさん＠お腹いっぱい。05/03/20 00:40:47
分ける必要はないが、別に分けても困らない。
ちなみに俺はピッチリ横分けだ。
0148名無しさん＠お腹いっぱい。2005/03/31(木) 16:42:19
ModularizationProposal - X.Org
http://wiki.x.org/wiki/ModularizationProposal
0149名無しさん＠お腹いっぱい。2005/03/31(木) 21:07:09
丁度こんなスレまってたんだよ．．．

先日セレ300Mhzでメモリ64MBでHDD6GBのシャープのPJ2っていう
SVGAモバイルノート購入したんですけども、FreeBSDインスコしたら
重くて使い物にならんのですよ。

ですんで、メインPCに対するモバイルXサーバにしようともくろんでる
のですが、どうやったらメインPCの方に接続できるのかわからんのです。

どっかにそういう使い方しているようなことについて書かれたHPとかないすか?
0150名無しさん＠お腹いっぱい。2005/03/31(木) 21:10:57
以下で分からないのなら、くだ質に行くのがおすすめ。

[モバイルXサーバ]
xhost +メインPC
[メインPC]
export DISPLAY=モバイルXサーバ:0

xdmを使っている場合はこの限りにあらず。
0151名無しさん＠お腹いっぱい。2005/03/31(木) 23:24:31
っつーかいい加減スクラッチしろよ
0152名無しさん＠お腹いっぱい。皇紀2665/04/01(金) 11:00:23
　　ﾀﾞ､ﾀﾞ､ﾀﾞﾘｰ ﾀﾞﾘ ♪
　　　　　　＼ｸｾｯ、ﾏﾏﾝ、ﾄﾞ､ﾏﾝﾄﾞｸｾｯ／
　　　　　　　♪　('A`) ♪
　　　　　　　 ＿ ノ　 )>＿ ｷｭｯｷｭ♪
　　　　　　／.◎。／◎｡／|
　　　　　　|￣￣￣￣￣|
■ このスレッドは過去ログ倉庫に格納されています