これはすごい!Windowsじゃ無理って思えるGUIアプリ
そもそもGNOMEってWindowsじゃ無理!って思えるものじゃないので次で MSが用意したものでお前が満足してんならそれでいいんじゃね
俺には無理だわ いいか悪いかではなく「MSが用意した」を
満足しない理由にしてる時点でダメだろうなw キモいから使ってないだけだよ
MSがキモくなくて便利な製品を出したら使うよ
キモいMSには頑張ってキモくない製品作ってほしいなぁ 結局「俺がMS嫌いだからMSはダメに決まってるだろ」でしかないのな。
信者って思考の底が浅いわ。 ダメに決まってないよ
お前がWindowsを選んで満足してるなら素晴らしいことだし
俺はお前がWindowsに満足してることを心から祝福できる ドザの人権すら認めない奴と思われたら心外だからね
いやはや、Windowsで満足していただきおめでとうございます
非常にWindowsがお似合いですよ バカなキチガイが必死になってMSとWindowsを否定しようとしてるだけだろ。 >>33
過疎板や過疎スレにならない為に窓厨が盛り上げてくれてます。 「DEはアプリケーションを含む統合環境である」でしょ
ウィンドウマネージャーと、操作性の統一性の欠片もなかった GUI アプリ群しかなかったところに登場したのが KDE / gnome 「DEはアプリケーションを含む統合環境である」でしょ
そこで言ってる「アプリケーション」を言えばいいのよ DEはアプリケーションを含むと言ってる時点で
アプリケーションはDEではないと区別できてるんだからさ だからDEじゃなくてアプリケーション名を言えというだけ バカか
自分で調べろ
本当に1分掛からないから
かつて LXDE と呼ばれていた lxqt を構成するアプリのリストなら
https://ja.wikipedia.org/wiki/LXQt
にある。他のDEでも同様であろう。私は全く興味が無いので調べる気はない。自分でやれ
なお KDE に全く依存しない環境が Debian 10 buster では提供されている
その意味でも LXQt は Qt のみに依存して環境構築できる、と言っていい 結論、Linuxには「Windowsじゃ無理」という素晴らしいアプリは存在しない。 そう思わないとWindowsなんて恥ずかしくて使ってらんないよね >>40
ここはアプリのリストを知るスレじゃなくて
そのリストの中から、すごいって思えるGUIアプリの
名前を言うスレだよw >>44
それがあるとどんな仕事がはかどりますか? 「そこで言ってる『アプリケーション』」を言うだけでは足りないっていうなら
>>36
> 「DEはアプリケーションを含む統合環境である」でしょ
> そこで言ってる「アプリケーション」を言えばいいのよ
ココに突っ込んでよ
>そこで言ってる「アプリケーション」を言えばいいのよ
ってのは、「アプリケーション」を言えば十分という意味であって、それだけで足りる
それ以外のことを示す必要はない 既に Windows に移植されてるから「無理」ではなくなっているけど登場時の gimp
多彩な機能を持ちつつ無料で、プロ仕様でなければ photoshop を不要たらしめた
Photoshop Elements って息してんの??
まあ逆をいえば、とりわけ qt 依存のアプリは軒並み容易に Windows 上で動くように出来るので
Linux でなければ無理と思えるアプリにはなりにくい cernの開発してるrootは速いし使いやすい
GUIで負荷の高いグラフをすばやく表示できる
どっちかっていうとすごいのは一緒に開発されてるllvmとかの方だけど 悪いちょっと聞いていいか?
この板いろんなとこでドザドザ言われてるけどなんなん? KVMとDockerとKubernetesだな
GUIアプリ?ない >>50
戌厨、いわゆるLinux信者がLinuxマンセーしない奴を片っ端からドザ認定して排除しようとしてるだけ デスクトップマネージャーはGUIアプリなのか・・・? compizに相当するのはWindowsにはDWMがあるだろ
パフォーマンス、互換性ともにcompizなんかより遥かに上だよ compizの珍妙なエフェクトを見てマジスゲェって感動してる変な子なんだろう。 ニコニコ動画にあるcompizのデモに「いらねぇ」「うぜぇ」の文字が流れまくるのは面白い。 >>57
> パフォーマンス、互換性ともにcompizなんかより遥かに上だよ
compizは完全な互換性をもちOpenGLを活用してパフォーマンスも問題ないが
DWMはGDIの性能が劣化するのでcompizの方がパフォーマンスは上
VistaのDWMではMFC等のGDIアプリにアクセラレーションがかからない
アクセラレーションがかかるのは.netアプリやDirect3Dアプリだけ
だから当時Windowsデスクトップアプリの大半がGDIアプリだったVistaでは
Aeroを切りXP互換で動かさないともっさりする
7以降のDWMではGDIのアクセラレーションが一部戻ったが完全にはかからない
7以降で完全にアクセラレーションされるのは.netのWPF、Direct3D、7新規APIの
Direct2D、8新規APIのWindowsRT
ttps://jehupc.ex@blog.jp/11464034/ (@とって)
ttps://nyaruru.hatena@blog.com/entry/20081126/p1 (@とって)
ttps://nyaruru.hatena@blog.com/entry/20090208/p1 (@とって)
ttps://ascii.jp/elem/000/000/730/730179/
ttps://docs.microsoft.com/en-us/windows/win32/learnwin32/overview-of-the-windows-graphics-architecture 英語わからないかもしれないから一番下のMSのページに書いてあることを適当に翻訳すると
Hardware Acceleration
...
While GDI supports hardware accleration for certain operations, many GDI operations are bound to the CPU.
Direct2D is layered on top of Direct3D, and takes full advantage of hardware acceleration provided by the GPU.
If the GPU does not support the features needed for Direct2D, then Direct2D falls back to software rendering.
Overall, Direct2D outperforms GDI and GDI+ in most situations.
GDIはある種の操作のハードウェアアクセラレーションに対応しているが、多くのGDI操作はCPUに
割り当てられる。Direct2DはDirect3D上にあるので、GPUによるハードウェアアクセラレーションの
完全な恩恵を受けられる。GPUがDirect2Dに必要な機能に未対応なら、Direct2Dはソフトウェア
レンダリングで実行される。全体としては、Direct2Dはほとんどの場面でGDIやGDI+より高性能だ。 もっさり描画は事実だからなぁ。
ただ、Direct3Dには無理でもOpenGLなら出来るなんて事も無いから、
compizも同様の制限を持つはず。ただ元がWindowsに対して大分もっさりしていたから、
制限がかかっても目立たなんじゃなかろうか。 >>57 >>60
ベンチなどで比較してくれないとサッパリわからないな カーネルがGUIか?ってのは置いとくとしても
WindowsのLinuxサブシステムでUbuntu動いたりするわけだからまったく無理というわけでもない >>60
compizやDWMの仕事はレンダリング済みのウインドウを最終的に板ポリゴンとして画面に描画することに過ぎず、
そんな簡単な処理がハードウェアアクセラレーションを完全に活用できるのはcompizだろうがDWMだろうが当たり前だ
GDIのハードウェアアクセラレーション云々はその前のウインドウ内のレンダリングの話であり、レイヤが違う
Linuxではウインドウ内のレンダリングは各アプリケーションに任されており、そもそも最初からソフトウェアレンダリングしているものが多い
62も言ってるけど、compiz以前に元々遅いんだよLinuxのGUIアプリは >>60
compizやDWMの仕事はレンダリング済みのウインドウを最終的に板ポリゴンとして画面に描画することに過ぎず、
そんな簡単な処理がハードウェアアクセラレーションを完全に活用できるのはcompizだろうがDWMだろうが当たり前だ
GDIのハードウェアアクセラレーション云々はその前のウインドウ内のレンダリングの話であり、レイヤが違う
Linuxではウインドウ内のレンダリングは各アプリケーションに任されており、そもそも最初からソフトウェアレンダリングしているものが多い
62も言ってるけど、compiz以前に元々遅いんだよLinuxのGUIアプリは >>66が正確に書いているけど
>compiz以前に元々遅いんだよLinuxのGUIアプリは
結局はこれに尽きる。
考え方が古いフレームワークが基盤にあるWindowシステムだと
うわ物がどんなに良くてもだめってことを示してる。
ただもうこの辺りは何十年も進歩してないから割り切っているんだと思う。 Direct2DがGDIやGDI+より高速なのは事実だよ
だけどGDIが主流の時代のアルゴリズムは
画面に表示されてない部分は描画を省くという
手法でその遅さをカバーしていた
今は表示されてない部分を含めてすべて描画してるので遅くなってる。
だから描画速度はDirect2Dの方が高速だけど
(そもそも描画してないから)昔のOSの方が軽く感じる。
そして今のOSでは(常に描画するので)GDIが速くなることはない。 GDIはアルゴリズムイントロダクションで紹介されてるような技法で構成されてる。
実数を扱えないのでどうしようかってところから編み出された古典であり基本なんですよ。
GDI+はエクスプレッションというお絵かきソフトを買い取って作ったもの。
エクスプレッション自体は大変出来の良いソフトで、たしか二人の数学者が作ってたと思います。
僕も買いました。
愛用してたわけじゃないですが。 GDIは一部の機能をハードウェアに任せることができたのも大きかったですね。
グラフィックアクセラレータというやつです。
DOSの時代には転送速度の速いET4000系列のグラフィックカードがもてはやされましたが、Windowsの時代になるとアクセラレータを搭載するS3系列に主役が変わったと思います。 >>66
LinuxのXアプリが使うXlib(GDIに相当)もXRender(GDI+やDirect2Dに相当)もちゃんと
ハードウェアアクセラレーションが掛かるよ
Nvidiaは知らないが、IntelとAMDのグラフィックボードの場合、X Serverは以前は
XAAというグラフィックボードの2Dアクセラレーションを活用する形で、現在は
GlamorというOpenGLを使ってグラフィックボードの3Dのアクセラレーションを
活用してXlibやXRenderをハードウェアアクセラレーションしている
ちなみにFirefoxはLinuxでもWindowsでもgtk+が使うCairoというレンダリング
ライブラリを使っていて、LinuxではXRender、WindowsではDirect2Dを使うので
ちゃんとハードウェアアクセラレーションされているし、ChromeもSkia経由で
同様にアクセラレーションされる
Vista以降のWindowsでは残念ながら今も多くのアプリが使うGDIのアクセラ
レーションが不十分なのでLinuxよりWindowsのDWMの方が劣っている >>69
> 画面に表示されてない部分は描画を省くという
これは今でも一緒だよ
WindowsでもXでも再描画が必要な部分がどこかWM_PAINTメッセージやExposeイベントで
送られてくるので、必要な範囲だけ再描画する
実際はコントロールやウィジット単位で再描画する実装になっているけどね
> 今は表示されてない部分を含めてすべて描画してるので遅くなってる。
いいえ
DWMやcompizのようなWindowの内容を保存するbacking storeを利用するシステムでは
ウィンドウの移動やウィンドウの順番変更のときはWM_PAINTやExposeが飛ばない
ちゃんと最適化されている
ちなみにDWMでGDIに問題が生じたのと違ってcompizでXlibの描画に問題が生じないのは
X Window Systemは20年以上前からbacking storeを利用したウィンドウ管理ができるように
なっていたから
ttp://xjman.dsl.gr.jp/X11R6/X11/CH03.html >>72
やり直し
ドキュメントを見る限り、cairoのxlibによるハードウェアアクセラレーションはビットマップのコンポジションが中心であり、
CPUレンダリングを完全に排除できるものではないように見える。実際のソースコードを参照し、主要なAPIがラスタリングにCPUを用いていないことを確認せよ。
また、Linuxのcairoを利用しているアプリの多くがxlibバックエンドを使っているかどうかは自明ではない。調査せよ。 >>74
ちゃんとソースコードみてね
現在はXlibではなくXRenderでの描画なので見るコードはcairo-xlib-render-compositor.c ちなみにXRender,fontconfig, Xft, carioこれらはすべてKeith Packardが作ったもの
同じ人物が作ったので効率的に動くように作られている
Keith PackardはXorgのX Serverの主要な開発者でもある
それとVistaが変なのはWin32APIを捨てて.netメインにする設計思想だったLonghornの
開発に失敗して成果の一部だけ取り込んだためだからこの辺の事情は考慮すべき https://nyaruru.はてなブログ.com/entry/20090208/p1
矩形描画系はWDDM1.1でハードウェアアクセラレーションが効く
線分や円については現在のGPUの描画の仕組みではCPUで描画した物と
寸分違わず全く同じ見た目にするのは無理だろう >>73
Vista以降はウインドウが最小化されていても
他のウインドウに隠れいても
WM_PAINTが飛んでくるんだよ
ウィンドウの移動やウィンドウの順番変更のときって
表示されてるかどうかと何の関係もないだろ バッキングストアは卓上の端末と電算室のコンピュータが遅い回線でつながれていた時代の名残ですよ。
とても素晴らしいものってわけではないです。 同じハードウェア上で同じ仕組みを使って動いているのに、
compiz(Linux)だけ旧来のGDIアクセラレータが動いていると思っている事が間違いじゃね。
そもそもの話、今時のGPUにGDIのアクセラレータなんぞが乗っているのだろうか? そもそもパソコンのハードウェアはWindows用に設計されてるので、Windowsで効率が良いのは当然なんですよ。 >>78
何を言いたいのかわからないのでVistaの描画システムの解説ページを貼るね
ttps://www.atmarkit.co.jp/fwin2k/vista_feature/05hardware/05hardware_03.html
従来のウィンドウ・システム
ウィンドウが動いたり、上下関係が変わるたびにリペイント・イベントが発生することになる。だが、たくさんの
アプリケーションで少ないメモリ(画面1枚分のメモリ)を共有するためにはしょうがないだろう。
Vistaのウィンドウ・システム
先ほど述べたように、ウィンドウの移動などに伴うリペイントが発生しないので、無駄なCPU時間の消費が抑えられる。
アプリケーションは自分自身のバッファ内にさえ描画しておけば、あとはすべてDWMが処理してくれる。
リペイント・イベント=WM_PAINTが飛ぶ
>>80
ちゃんと>>72で書いたつもりなんだけど、現行のシステムの場合compizもその上で動くアプリも
最終的にOpenGLの3Dアクセラレーションを利用する
忘れていたけどcairoは直接OpenGLをバックエンドに描画することもできます さすがにGUIで窓や林檎に勝ってると思う奴は気がふれてる Downloadのページ開いたらてっぺんにsetup64.exeがあってワロタ Wayland対応がまともなのはGNOMEしかないな
設計はXよりきれいになったけど xface
unix でも最近あまり見ないが、あの味はwindows では難しかろう Xfceはエックスフェイスではなくエックスエフシーイーである >>90
ネットワーク上のマシンのload average をrwhoで取得して顔で表示するアプリの事だぞ? 88で書いたのは。
念のため >>91
>>90
すまん、xface じゃなくて xloadface だったわ。 https://tutorialmore.com/questions-578178.htm
まず1段階目、CPU負荷をネットワーク経由で取得できるか?調べたらできるようだ。
ならWindowsでも実現できるね。 >>94
数値じゃないよ、あの(無駄な?)味わいの話だよ。
windows でも作れなくはないだろうけど、作らんでしょ? クラスルーム向けX11アプリ共有ツール XMX
http://cs.brown.edu/software/xmx/
コンプライアンスとコスパを両立させようとするとWindowsじゃ無理 どうだろう。犬厨が考えるコスパ(笑)ってのは、機材が無料で手に入って人材も無償で使い放題な状況だから、
コンプライアンス的には真っ黒だろう。 >>98
犬厨って 林 檎 と 白 い お 父 さ ん 犬 が大好きなア フォ ン厨の事ですよ。
でもアッポレOSはWindowsと違って恐怖のiesysとA gentBaseに感染しないから、
身に覚えのない誤 認 逮 捕をされないんだお(笑) MacOS
今のMacOSって単なるDEなんだけど、OSと勘違いしている人がやたらと多い。 Linux
昔からLinuxはカーネルであってOSじゃないんだけど
OSと勘違いしてる人がやたら多い
OSとはAndroidやUbuntuのこと どうでもいい知識をドヤ顔で書くのもちょっと恥ずかしいね ターミナル(エミュレータ)
ターミナルだけはWindowsでは絶対むーりー コマンドプロンプトとかアレルギー発作起きるで コマンドプロンプトは
dockerとか、mklinkとかたまに使うけど
使いにくいね、