2011-01-02 13 views
37

私がきたものからAndroidのグラフィックスの内部

を私は、Androidのグラフィックスシステムがどのように機能するかについて明確な説明を発見していない具体的には、ディスプレイ・サーバを使用しない、それはDirectFBのかX11に基づいており、などAndroidはLinux frame bufferに依存しています。私はフレームサーバーへのアクセスを多重化するためにどのような種類のディスプレイサーバーまたはwindow managerが使用されているかについてはあまり見当たりませんでした。

最後に、ARM命令セットはOpenGLを高速化するための命令を提供していますが、これがディスプレイサーバーとどのように統合されるかは明確ではありません。クライアントアプリケーションは、クライアントが直接書き込む共有メモリバッファをネゴシエートしますか?

プラットフォームアクセラレータ用のOpenGLライブラリはオープンソースですか?私はクローズドソースバイナリであることを示唆する参考文献をいくつか見つけました。ここでも、どんなポインタも評価されます。

+0

+1。突然表示に関連する問題を与えられている私のような人には非常に便利です:)あなたはLinuxフレームバッファのリンクを修正してください。それは変更され、それ以上サポートされていません。事前にありがとうございます.. –

答えて

38

Androidグラフィックスには、SurfaceFlingerとSkiaの2つのコアピースがあります。 SurfaceFlingerは、Windowsのコンポジタであり、ウィンドウ(実際にはサーフェス)を作成して表示するために使用されます。SurfaceFlingerは、現在OpenGL ES 1.xの上に実装されています(MDP、 T-Mobile G1、またはXoomのハードウェアオーバーレイ)

各アプリケーションは、主にSkiaを使用してウィンドウ(またはサーフェス)にレンダリングします。 SkiaはAndroidの2Dグラフィックライブラリです。 OpenGL ES 1.xおよび2.0を使用してサーフェスにレンダリングすることもできます。

Androidは、DirectFBまたはX11または他の既存のLinuxソリューションを使用していません。 http://www.slideshare.net/jserv/design-and-concepts-of-android-graphics

+0

とウィンドウマネージャは、すべてのプログラムで共有されている識別プロセスです、従来のディスプレイサーバーに似ていますか? – naasking

+0

ウィンドウマネージャはsystem_processにありますが、SurfaceFlingerはウィンドウマネージャではなく表示デバイスを所有しています。 –

+0

DirectFBへのあなたのコメントが不思議です。 [Jim Huangのプレゼンテーション](http://www.slideshare.net/jserv/design-and-concepts-of-android-graphics)のプレゼンテーションを見ると、スライド30と31のフレームバッファへの参照に気付くでしょう。 DirectFBとの違いは? – CyberFonic

8

Androidのグラフィックスについての簡単な紹介のプレゼンテーションがあります。しかし、Android 3.0以来のことが変わった。 Skiaはもはやそれほど重要ではありません。ほとんどの2D図面は、OpenGL、a.k.a HWUIコンポーネントを使用して高速化されています。

+0

注意:最新バージョンはかなり変更されています。スライドに含まれている情報が古くなっている可能性があります。 –

4

ロマン・ガイは間違いなく正しかった:

+0

Androidグラフィックススタックを学ぶのに適したスタートポイントは何ですか? – control

+0

@ppu私のブログhttp://pierrchen.blogspot.com/を恥知らずに宣伝しました。内部でアンドロイドのグラフィックスについてかなり話しました。 – pierrotlefou

+1

HWUIをデバッグしたいのですが、どうやってやるのか分かりません。どんなログも出せません(PS:あなたは中国人でも私ですので、手を貸してください)。 – kangear

関連する問題