Linuxは画面周りの処理が重いからGUIで使うにはちょっと

374 : 2021/08/29(日) 13:05:14.19 ID:azwmeVQK: Linuxは画面周りの処理が重いからなぁ。
関数レベルで時間計測するような計り方するとはっきりした傾向として判るけどね。
今どきそんなことしてまで性能計る奴がいるかは知らんが。
376 : 2021/08/29(日) 18:41:02.92 ID:fT5DORQB: 画面周りの処理が重いなんてハードウェアリソースでどうにもなるし、太古のX11が今日も動いていてくれる方が嬉しいよｗｗｗ
378 : 2021/08/31(火) 03:59:46.90 ID:arYJEgMB: 嘘乙。
Xは作りが悪すぎてハードの性能あげたところで遅いまま。
379 : 2021/08/31(火) 05:48:21.80 ID:cThO2+jw: 悪いというのは言い過ぎだろうが、ネットワーク透過にできるようにする為の構造やら縛りやらのせいで
パフォーマンスが出せないのは確か
それもあってwaylandとかmir（立ち消えになったが）とかで何とかしようって事になったんだろうけど
単純過ぎてやはり直接の使い手側（特にツールキットやフレームワークの類）に負担を押し付けてる格好
やっぱり汚いだの見通しが悪いだの言われようとも、言語を択ばずにGUI部品（コントロール類）の再利用が
実際にできてるWindowsのメッセージの構造は良くできてる
380 : 2021/08/31(火) 06:18:14.80 ID:MFTyA6eM: Wikiにはこんな事が書いてあるよ。

Xのネットワーク機能が過度に複雑であるために、ローカルで使っても性能に悪影響があるという誤解を持つ人が多いが、現在のXの実装ではローカルな接続では単にソケットと共有メモリを使うので、X固有のオーバーヘッドはほとんどない。
384 : 2021/08/31(火) 07:37:45.51 ID:cThO2+jw: >>380
共有メモリとソケット（ストリーム化された描画命令等）を介さなければならない時点で
オーバーヘッドは必ず存在するし、ウィンドウ（コントロール）１つだけの
パフォーマンスじゃなくって１つのプロセスからの描画命令をバッファリングして
ウィンドウシステム側でマルチコアを活用しての並列な描画で矛盾なくUIを更新できるか、
更に複数のプロセスからの描画命令を並列に処理できるかどうかが
複数コア＆HT当たり前のご時世でのパフォーマンスに影響してくる

ドメインソケットって単語が出てこない辺りにわかなんだろうが、
ウィンドウシステムってのは素人が思ってる程単純な代物ではない
381 : 2021/08/31(火) 06:29:32.48 ID:TE+z1ZCv: クライアントサーバー形式でのオーバーヘッドが無いだけでXが重いことには変わりないぞ
382 : 2021/08/31(火) 07:17:03.60 ID:2iICx8lQ: 中身も外見も時代遅れ、時代錯誤な愚鈍なXさんはハードを変えたところでムダだわな。
Xって元からハードの性能活かせないタコな作りしてるし。
383 : 2021/08/31(火) 07:24:16.67 ID:H+S8K3nl: X の問題遅いとか言うよりもGUIのデザインが統一できないとか
そういうところだと思うわ
みんな好きかってやるから
基本的なGUI部品は統一すべきだったと思う
385 : 2021/08/31(火) 07:48:34.73 ID:H+S8K3nl: X固有のオーバーヘッドはほとんどないよ！
ソケットと共有メモリのオーバーヘッドだけだよ！
388 : 2021/08/31(火) 09:04:44.13 ID:rREjsx77: WindowsのLinuxもChromeOSのLinuxもXではなくWaylandを採用してるな
389 : 2021/08/31(火) 10:30:07.43 ID:cThO2+jw: Waylandを採用してても未だに多くがxlib互換のライブラリを通してるから
無駄が省ききれてない上にWaylandが過去のしがらみから脱却し切れてない
391 : 2021/08/31(火) 20:20:28.35 ID:cThO2+jw: その究極系がXWaylandサーバだが、
それを使い続ける限りオーバーヘッドが一気に解消されるなんて事はないだろう

それが悪いだの何だのではなく、ウィンドウシステムがWaylandになったからと言って
飛躍的にオーバーヘッドが減るとかパフォーマンスが上がるとかそんな事はないっていうお話