私はGUIプログラミングを始めており、いくつかの調査を行いました。今、すべてがはっきりしているわけではありません。GTK+ をツールキットとして使用する場合、グラフィックス カードとどのように通信しますか?
Linux システムでは、GTK --> X Server --(OpenGL)--> グラフィックス カードになると思います。これは正しいですか？
一部の GUI は OpenGL を直接描画する (例: Blender3D) と読みましたが、他のアプリはどのように GUI を描画しますか?
グラフィックス カード用の (私が知っている) API が Direct3D と OpenGL だけである場合、ソフトウェア レンダリングとハードウェア アクセラレーションの違いは何ですか?
「ソフトウェア レンダリング」を行うソフトウェアは、グラフィック カードのフレームバッファに直接書き込むことができるので、OpenGL は変更されませんか?
PS：多くの質問をして申し訳ありませんが、すべての回答に感謝します:)
Linux システムでは、GTK --> X Server --(OpenGL)--> グラフィックス カードになると思います。これは正しいですか？
いいえ。Linux の GTK+ は
/-[ if direct context ]---\
/--> OpenGL >-+---------/ \
/ \-> GLX -+--------------\ \
/ \ \ \
GTK+ -+-> cairo >-+---> XRender >--------+----+-> Xlib/xcb >-+-> X server >-+-> Kernel Module >-> GPU
\ \–-> pixmap buffer >–/
\ /
\―---------------------------/
一部の GUI は OpenGL を直接描画する (例: Blender3D) と読みましたが、他のアプリはどのように GUI を描画しますか?
それは単なる「ブレンダー」です（末尾の3Dはありません）。Blender の GUI ツールキットは、唯一のバックエンドとして OpenGL を使用しています。しかし、GUI は OpenGL を使用して直接描画されるわけではありません。これを使用すると、作業が面倒になります (OpenGL 呼び出しを使用してすべてのボタンを描画します。Blender には独自のツールキットがあります。GTK+ は別のツールキットですが、Blender には関連付けられていません (実際には、1 つの私のお気に入りのプロジェクトの 1 つは、独立したプロジェクトで使用できるように、Blender の GUI ツールキットを抽出しています)。
GTK+ や Qt などのツールキットは、移植性を最大限に高めるように設計されています。Blender には、OpenGL が利用可能になることを知っている贅沢があります。GTK+ または Qt 用に開発されたアプリは、3D 対応でないシステムで実行できる場合があるため、GTK+ および Qt の設計により、多くのバックエンドで実行できます。バージョン 3 の GTK+ は、Cairo グラフィック エンジンをグラフィック バックエンドとして使用します。Cairo にも独自のバックエンドがあります。つまり、ピックスマップ (ピクセル イメージ) に描画するソフトウェア ラスタライザー、または下層のグラフィックス アーキテクチャに描画コマンドをプロキシします。Linux 上の Cairo の場合、これは OpenGL または X11 (コアおよび XRender プロトコル拡張) のいずれかです。
グラフィックス カード用の (私が知っている) API が Direct3D と OpenGL だけである場合、ソフトウェア レンダリングとハードウェア アクセラレーションの違いは何ですか?
OpenGL も Direct3D もグラフィックス カードと通信しません。グラフィックカードのドライバーと通信します。したがって、OpenGL と Direct3D をバイパスして、自分でドライバーに話しかけるという選択肢があります。しかし、なぜこれを行うのですか？面倒です。
Windows ではさらに、描画用の GDI や WPF (Windows Presentation Foundation)、および Direct2D があります。
Linux では、素敵な絵を描くための X11 コアと XRender 拡張プロトコルを利用できます。
上昇中のもう 1 つの API は OpenVG で、これらすべての 2D 描画 API の標準化を目指しています。そして、少なくとも Linux では、OpenGL と OpenVG が、フレームバッファとユーザー入力を管理するためのウィンドウ システムを備えた、長期的に利用可能な唯一の抽象描画 API になるように選択されています。開発中の Wayland (私が完全に嫌いなデザイン) と X11 の方が優れたデザインだと思います (ネットワーク指向のシステムで、分散実行が可能で、将来的に非常に重要だと考えています)。いくつかの「X12」への完全なオーバーホール - レガシーなクラフトを一掃し、接触色空間で動作させ、接続を移行可能にします (X サーバー間でクライアントを移行できるようにします。これにより、X セッションをロックするはるかに洗練された方法が可能になります) 、
「ソフトウェア レンダリング」を行うソフトウェアは、グラフィック カードのフレームバッファに直接書き込むことができるので、OpenGL は変更されませんか?
最新のオペレーティング システムではありません。ただし、OS はフレームバッファ API (Linux では /dev/fb0) を介してグラフィックス カードへの抽象化されたアクセスを提供する場合があります。ただし、フレームバッファは管理されていないため、X サーバーまたは Wayland が実行されている場合、それらのいずれかが FB を管理するタスクにあり、それはあなたの仕事ではありません。
「ソフトウェア レンダリング」を行うソフトウェアは、グラフィック カードのフレームバッファに直接書き込むことができるので、OpenGL は変更されませんか?
正確ではありませんが、ドライバーによって異なります。XServer (または Windows や MacOS の同等物) のような表示システムは、API を使用せず、むしろ API を記述します。具体的には、ディスプレイ ドライバーが満たさなければならないドライバー モデル (XServer の場合は、XAA、EXA、UXA、DRI などの複数のモデルの 1 つ) と呼ばれます。
これらのモデルで定義されていないことはすべて「ソフトウェア」で実行し、CPU で計算する必要があります。さらに、モデルによって定義された操作の一部は、ドライバーによって CPU 上で計算される場合もあります。
OpenGL は、これらのモデルとは完全に別の標準でした。グラフィックス ドライバーは、OS で使用するために OpenGL を実装する必要はまったくありませんでした。しかし、最新の OS での 3D グラフィックスとより複雑な合成の継続的な統合により、ドライバー モデルは OpenGL や Direct3D と同じパラダイムに依存し始めています。たとえば、WDDM (Windows Display Driver Model) には Direct3D 9 のサポートが完全に必要です。