Windows と C++

[アーティクル]
2015-06-12

Direct2D によるレイヤードウィンドウ

Kenny Kerr

Direct2D に関する 3 回目のコラムとなる今回は、相互運用性に比類なき能力を発揮する機能の一部を紹介します。Direct2D が提供するさまざまな相互運用性オプションをすべて詳しく説明するのではなく、実用的なアプリケーションであるレイヤードウィンドウについて説明します。レイヤードウィンドウは、古くからあるウィンドウ機能の 1 つですが、あまり進化していないため、最新のグラフィックステクノロジと効果的に併用するには特別な注意が必要です。

このコラムは、Direct2D プログラミングについて基本的な知識があることが前提です。基本的な知識をお持ちでない方は、Direct2D を使用したプログラミングと描画の基本事項を紹介した、6 月号のコラム (msdn.microsoft.com/ja-jp/magazine/dd861344) と 9 月号のコラム (msdn.microsoft.com/magazine/ee413543、英語) をお読みいただくことをお勧めします。

本来、レイヤードウィンドウは、いくつか異なる目的に使用されてきました。具体的には、レイヤードウィンドウを使用すると、視覚効果やちらつきのないレンダリングを簡単かつ効率的に実現できます。GDI がグラフィックスを作成する際の主流だった頃は、これは本当に思いがけず嬉しいものでした。ところが、ハードウェアアクセラレータが登場した現在では、こうした魅力は色あせてしまいました。レイヤードウィンドウでは、まだ User32/GDI が扱われており、パフォーマンスや品質の高いグラフィックスを実現するマイクロソフトプラットフォームである DirectX をサポートするという、重要な更新が行われていないためです。

レイヤードウィンドウには、ピクセル単位にアルファブレンドを行ってデスクトップ上のウィンドウを組み立てるという独特の機能があります。こうした機能は、Windows SDK を使う方法では実現できません。

実際のレイヤードウィンドウには、2 種類の方式があります。その違いは、ピクセル単位に不透明度を制御するか、ウィンドウ全体で不透明度を制御するかにあります。今回のコラムでは、前者について説明しますが、実際にウィンドウ単位に不透明度を制御する場合でも、ウィンドウを作成してから SetLayeredWindowAttributes 関数を呼び出してアルファ値を設定するだけです。

Verify(SetLayeredWindowAttributes(
  windowHandle,
  0, // no color key
  180, // alpha value
  LWA_ALPHA));

ここでは、WS_EX_LAYERED 拡張スタイルを指定してウィンドウを作成しているか、SetWindowLong 関数の使用後にこのスタイルを適用していることを前提とします。このようなウィンドウの例を図 1 に示します。このメリットは明白で、デスクトップウィンドウマネージャー (DWM) によって自動的にウィンドウが適切にブレンドされるため、アプリケーションでウィンドウを描画する方法を何も変更する必要はありません。そうでなければ、自分ですべてを完全に描画する必要があります。もちろん、Direct2D などの新しいレンダリングテクノロジを使用していれば問題ありません。

Window with Alpha Value

図 1 アルファ値によるウィンドウ

では、どのようなことが必要でしょうか。根本的なレベルでは簡単です。まず、UPDATELAYEREDWINDOWINFO 構造体に値を設定します。この構造体は、レイヤードウィンドウの位置とサイズと、ウィンドウの表示面を定義する GDI デバイスコンテキスト (DC) を提供します。問題はここにあります。DC は、GDI という古い環境を使用しているため、DirectX やハードウェアアクセラレーションを使用する環境とは大きく異なります。これについてはすぐに説明します。

自身で割り当てる必要がある構造体へのポインターがいっぱいあることに加え、Windows SDK には、UPDATELAYEREDWINDOWINFO 構造体についての十分な説明がないため、使用方法はあまり明確になっていません。全体では、5 つの構造体を割り当てる必要があります。DC からコピーするビットマップの位置を特定するソース位置の構造体、更新時にウィンドウが配置されるデスクトップ上の位置を特定するウィンドウ位置の構造体、コピーするビットマップのサイズ (ウィンドウのサイズも定義します) を示す構造体があります。

POINT sourcePosition = {};
POINT windowPosition = {};
SIZE size = { 600, 400 };

また、レイヤードウィンドウをデスクトップとブレンドする方法を定義する BLENDFUNCTION 構造体があります。これは、見過ごされがちですが、驚くほど万能な構造体で、非常に便利です。通常、次のように設定します。

BLENDFUNCTION blend = {};
blend.SourceConstantAlpha = 255;
blend.AlphaFormat = AC_SRC_ALPHA;

AC_SRC_ALPHA 定数は、ソースビットマップにアルファチャネルが含まれていることを示します。これが最も一般的なシナリオです。

ただし、興味深いことに、SourceConstantAlpha は、SetLayeredWindowAttributes 関数を使用してウィンドウ全体の不透明度を制御することとほぼ同じです。SourceConstantAlpha に 255 を設定すると、レイヤードウィンドウはピクセル単位にアルファ値を使用します。しかし、これを完全にゼロ (完全に透明) にすると、再描画の手間をかけることなく、ウィンドウのフェードインまたはフェードアウトなどの効果を実現できます。これで、BLENDFUNCTION 構造体の名前の由来が明らかになったのではないでしょうか。アルファブレンドを適用した結果のウィンドウは、この構造体の値の関数になります。

最後の構造体は、すべてを結び付ける UPDATELAYEREDWINDOWINFO です。

UPDATELAYEREDWINDOWINFO info = {};
info.cbSize = sizeof(UPDATELAYEREDWINDOWINFO);
info.pptSrc = &sourcePosition;
info.pptDst = &windowPosition;
info.psize = &size;
info.pblend = &blend;
info.dwFlags = ULW_ALPHA;

これについては、改めて説明することもなく一目瞭然です。説明していないメンバーは dwFlags 変数だけです。このメンバーの値 ULW_ALPHA は、以前に古い UpdateLayeredWindow 関数を使用したことがあれば見覚えがあるはずです。これは、ブレンド関数を使用することを示しているだけです。

最後に、ソース DC へのハンドルを指定し、UpdateLayeredWindowIndirect 関数を呼び出してウィンドウを更新する必要があります。

info.hdcSrc = sourceDC;

Verify(UpdateLayeredWindowIndirect(
  windowHandle, &info));

これだけです。ウィンドウは、WM_PAINT メッセージを受け取りません。ウィンドウの表示または更新が必要になるたびに、UpdateLayeredWindowIndirect 関数を呼び出すだけです。この定型コードを使用しないようにするには、図 2 に示す LayeredWindowInfo ラッパークラスを使用します。

図 2 LayeredWindowInfo ラッパークラス

class LayeredWindowInfo {
  const POINT m_sourcePosition;
  POINT m_windowPosition;
  CSize m_size;
  BLENDFUNCTION m_blend;
  UPDATELAYEREDWINDOWINFO m_info;

public:

  LayeredWindowInfo(
    __in UINT width,
    __in UINT height) :
    m_sourcePosition(),
    m_windowPosition(),
    m_size(width, height),
    m_blend(),
    m_info() {

      m_info.cbSize = sizeof(UPDATELAYEREDWINDOWINFO);
      m_info.pptSrc = &m_sourcePosition;
      m_info.pptDst = &m_windowPosition;
      m_info.psize = &m_size;
      m_info.pblend = &m_blend;
      m_info.dwFlags = ULW_ALPHA;

      m_blend.SourceConstantAlpha = 255;
      m_blend.AlphaFormat = AC_SRC_ALPHA;
    }

  void Update(
    __in HWND window,
    __in HDC source) {

    m_info.hdcSrc = source;

    Verify(UpdateLayeredWindowIndirect(window, &m_info));
  }

  UINT GetWidth() const { return m_size.cx; }

  UINT GetHeight() const { return m_size.cy; }
};

図 3 は、ATL/WTL と図 2 の LayeredWindowInfo ラッパークラスを使用したレイヤードウィンドウの基本構造を示しています。最初に注目するのは、WM_PAINT を使用しないため、UpdateWindow を呼び出す必要がないことです。代わりに、すぐに Render メソッドを呼び出します。このメソッドは、次になんらかの描画を実行したり、LayeredWindowInfo の Update メソッドに DC を指定したりするのに必要です。おもしろくなるのは、描画がどのように行われ、DC がどこから取得されるかというところからです。

図 3 レイヤードウィンドウの構造

class LayeredWindow :
  public CWindowImpl<LayeredWindow, 
  CWindow, CWinTraits<WS_POPUP, WS_EX_LAYERED>> {

  LayeredWindowInfo m_info;

public:

  BEGIN_MSG_MAP(LayeredWindow)
    MSG_WM_DESTROY(OnDestroy)
  END_MSG_MAP()

  LayeredWindow() :
    m_info(600, 400) {

    Verify(0 != __super::Create(0)); // parent
    ShowWindow(SW_SHOW);
    Render();
  }

  void Render() {
    // Do some drawing here

    m_info.Update(m_hWnd,
      /* source DC goes here */);
  }

  void OnDestroy() {
    PostQuitMessage(1);
  }
};

GDI/GDI+ の方法

最初に、GDI/GDI+ の描画のしくみを示します。まず、青、緑、赤、アルファ (BGRA) の順にバイト列を並べたカラーチャネルを使用して、プリマルチプライ処理済みの 32 ビット/ピクセル (bpp) のビットマップを作成します。プリマルチプライ処理済みとは、カラーチャネル値とアルファ値があらかじめ乗算されていることを意味します。これにより、アルファブレンドを行うイメージのパフオーマンスが向上しますが、本来のカラー値を取得する際に、カラー値をアルファ値で除算するという逆の処理を実行しなければならないことを意味します。GDI 用語では、これは 32 bpp のデバイスに依存しないビットマップ (DIB) と呼ばれ、BITMAPINFO 構造体に情報を指定し、その構造体を CreateDIBSection 関数に渡すことで作成されます (図 4 参照)。

図 4 DIB の作成

BITMAPINFO bitmapInfo = {};
bitmapInfo.bmiHeader.biSize = 
  sizeof(bitmapInfo.bmiHeader);
bitmapInfo.bmiHeader.biWidth = 
  m_info.GetWidth();
bitmapInfo.bmiHeader.biHeight = 
  0 – m_info.GetHeight();
bitmapInfo.bmiHeader.biPlanes = 1;
bitmapInfo.bmiHeader.biBitCount = 32;
bitmapInfo.bmiHeader.biCompression = 
  BI_RGB;

void* bits = 0;

CBitmap bitmap(CreateDIBSection(
  0, // no DC palette
  &bitmapInfo,
  DIB_RGB_COLORS,
  &bits,
  0, // no file mapping object
  0)); // no file offset

ここには細かい情報がたくさんありますが、今回の説明には関係ありません。この API 関数は古くからあります。注意すべき点は、ビットマップの高さに負の値を指定していることです。BITMAPINFOHEADER 構造体では、ボトムアップまたはトップダウンのいずれかでビットマップを定義します。高さが正であればボトムアップのビットマップになり、負であればトップダウンのビットマップになります。トップダウンビットマップの原点は左上隅で、ボトムダウンビットマップの原点は左下隅です。

ここでトップダウンを指定することは厳密には必要ではありませんが、Windows での最近のイメージングコンポーネントのほとんどがトップダウンのビットマップを使用する傾向があるため、このように指定しておくと相互運用性が向上します。これにより、ストライドが正になり、次のように計算します。

UINT stride = (width * 32 + 31) / 32 * 4;

これで、ビットポインターを介してビットマップの描画を開始するための十分な情報が揃いました。当然、支障がない限り、なんらかの描画関数を使用することになりますが、残念なことに、GDI が提供する関数の多くは、アルファチャネルをサポートしません。そこで、GDI+ の登場となります。

ビットマップデータを直接 GDI+ に渡してもかまいませんが、UpdateLayeredWindowIndirect 関数に渡すためにはどうしても DC が必要になるため、DC を作成しましょう。DC を作成するには、CreateCompatibleDC というわかりやすい名前の関数を呼び出し、デスクトップと互換性のあるメモリ DC を作成します。その後、SelectObject 関数を呼び出して DC に書き込むビットマップを選択できます。図 5 に示す GdiBitmap ラッパークラスは、これらの処理をすべてラップしたうえで、追加のハウスキーピング処理も提供します。

図 5 DIB ラッパークラス

class GdiBitmap {
  const UINT m_width;
  const UINT m_height;
  const UINT m_stride;
  void* m_bits;
  HBITMAP m_oldBitmap;

  CDC m_dc;
  CBitmap m_bitmap;

public:

  GdiBitmap(__in UINT width,
            __in UINT height) :
    m_width(width),
    m_height(height),
    m_stride((width * 32 + 31) / 32 * 4),
    m_bits(0),
    m_oldBitmap(0) {

    BITMAPINFO bitmapInfo = { };
    bitmapInfo.bmiHeader.biSize = 
      sizeof(bitmapInfo.bmiHeader);
    bitmapInfo.bmiHeader.biWidth = 
      width;
    bitmapInfo.bmiHeader.biHeight = 
      0 - height;
    bitmapInfo.bmiHeader.biPlanes = 1;
    bitmapInfo.bmiHeader.biBitCount = 32;
    bitmapInfo.bmiHeader.biCompression = 
      BI_RGB;

    m_bitmap.Attach(CreateDIBSection(
      0, // device context
      &bitmapInfo,
      DIB_RGB_COLORS,
      &m_bits,
      0, // file mapping object
      0)); // file offset
    if (0 == m_bits) {
      throw bad_alloc();
    }

    if (0 == m_dc.CreateCompatibleDC()) {
      throw bad_alloc();
    }

    m_oldBitmap = m_dc.SelectBitmap(m_bitmap);
  }

  ~GdiBitmap() {
    m_dc.SelectBitmap(m_oldBitmap);
  }

  UINT GetWidth() const {
    return m_width;
  }

  UINT GetHeight() const {
    return m_height;
  }

  UINT GetStride() const {
    return m_stride;
  }

  void* GetBits() const {
    return m_bits;
  }

  HDC GetDC() const {
    return m_dc;
  }
};

デバイスに描画するためのメソッドを提供する GDI+ Graphics クラスは、ビットマップの DC を使用して構築できます。図 6 は、図 3 の LayeredWindow クラスを更新して、GDI+ によるレンダリングをサポートする方法を示します。定型の GDI コードすべてを除くと、このコードはかなり簡単です。ウィンドウのサイズを GdiBitmap コンストラクターに渡し、ビットマップの DC を Graphics コンストラクターと Update メソッドに渡します。簡単ですが、GDI も GDI+ も (ほとんど) ハードウェアアクセラレータが使用されておらず、特に強力なレンダリング機能も提供していません。

図 6 GDI レイヤードウィンドウ

class LayeredWindow :
  public CWindowImpl< ... {

  LayeredWindowInfo m_info;
  GdiBitmap m_bitmap;
  Graphics m_graphics;

public:
  LayeredWindow() :
    m_info(600, 400),
    m_bitmap(m_info.GetWidth(), m_info.GetHeight()),
    m_graphics(m_bitmap.GetDC()) {
    ...
  }

  void Render() {
    // Do some drawing with m_graphics object

    m_info.Update(m_hWnd,
      m_bitmap.GetDC());
  }
...

アーキテクチャの問題

対照的に、Windows Presentation Foundation (WPF) では、次のようにレイヤードウィンドウを作成するだけです。

class LayeredWindow : Window {
  public LayeredWindow() {
    WindowStyle = WindowStyle.None;
    AllowsTransparency = true;

    // Do some drawing here
  }
}

これは、驚くほど簡単ですが、レイヤードウィンドウに関連する複雑性やレイヤードウィンドウを使用する際のアーキテクチャの制限に反します。どんなに簡単に見えても、レイヤードウィンドウは、このコラムで概要を説明したアーキテクチャの原則に従わなければなりません。WPF ではレンダリングにハードウェアアクセラレータを使用できることもありますが、UpdateLayeredWindowIndirect 関数を呼び出して表示を更新する前に、互換性のある DC に選択したプリマルチプライ処理済み BGRA ビットマップに結果をコピーする必要があります。WPF はブール型の変数以外は公開していないため、代わりに特定の選択を行う必要があり、この選択を制御することはできません。なぜ問題なのでしょうか。問題はハードウェアです。

グラフィックプロセッシングユニット (GPU) には、専用メモリを使って最適なパフォーマンスを実現するメリットがあります。つまり、既存のビットマップを操作する必要がある場合は、そのビットマップをシステムメモリ (RAM) から GPU メモリにコピーする必要があります。このコピーは、多くの場合、システムメモリどうしでコピーを行うよりも時間がかかります。逆も同じです。GPU を使用してビットマップを作成およびレンダリングする場合、そのビットマップをシステムメモリにコピーすることになると、これも負荷の高いコピー操作です。

通常、GPU がレンダリングしたビットマップはディスプレイデバイスに直接送信されるため、この問題は発生しません。レイヤードウィンドウの場合、User32/GDI リソースはカーネルモードリソースにもユーザーモードリソースにも関係し、どちらもビットマップへのアクセスを必要とするため、ビットマップをシステムメモリに戻さなければなりません。たとえば、User32 がレイヤードウィンドウのヒットテストを実行する必要があるとします。レイヤードウィンドウのヒットテストは、ビットマップのアルファ値に基づいており、特定の点のピクセルが透明であっても、マウスメッセージを送信できます。そのため、これを可能にするには、システムメモリ内にビットマップのコピーが必要です。ビットマップが UpdateLayeredWindowIndirect によってコピーされたら、DWM がデスクトップを構成できるように、GPU に直接戻されます。

GPU とシステム間でメモリをコピーするコストに加え、GPU を CPU と同期するコストもかかります。CPU を集中的に使用する一般的な操作とは異なり、GPU の操作は非同期に行われる傾向があります。これにより、一連のレンダリングコマンドをバッチ処理する際に優れたパフォーマンスが実現します。CPU とのやり取りが発生すると、そのたびにバッチ処理コマンドがフラッシュされ、CPU は GPU が処理を完了するまで待機することになり、結果として、パフォーマンスは最適とは言えなくなります。

つまり、このようなラウンドトリップやその頻度とコストについて注意する必要があります。レンダリングするシーンが複雑すぎると、ビットマップのコピーにかかるコストが、ハードウェアアクセラレータによって得られるパフォーマンスのメリットを簡単に上回ります。一方、レンダリングにそれほど高いコストがかからず、CPU で実行できる場合は、ハードウェアアクセラレータを選ばなくても、最終的に、パフォーマンスが向上することがわかります。このような選択は容易ではありません。GPU の中には専用のメモリを備えておらず、システムメモリの一部を使用するものもあります。このような場合は、コピーのコストは少なくなります。

GDI でも WPF でも選択の余地がないことが問題です。GDI では、CPU を使用するしかありません。WPF では、どのようなレンダリング方法を使用しても、通常、Direct3D のハードウェアアクセラレーションの使用を余儀なくされます。

そこに登場したのが Direct2D です。

Direct2D と GDI/DC

Direct2D は、選択する対象が何であってもレンダリングを行うように設計されました。対象がウィンドウや Direct3D テクスチャであれば、Direct2D は、コピーを伴うことなく、GPU に直接レンダリングします。対象が Windows Imaging Component (WIC) ビットマップであれば、CPU を代わりに使用して、同じように直接レンダリングします。WPF は GPU への多くのレンダリングを試み、レンダリングできない場合はソフトウェアラスタライザーを使用します。それに対して Direct2D は、ハードウェアアクセラレーションを利用できる場合は GPU の優れたイミディエイトモードレンダリングを使用し、GPU が使用できない場合や使用が望ましくない場合は、CPU に最も適したレンダリングを行うことによって、両方のメリットを活かします。

ご想像どおり、Direct2D を使用してレイヤードウィンドウをレンダリングする方法は多数あります。いくつかの方法を見てみましょう。ここでは、ハードウェアアクセラレーションを使用するかどうかに応じて、それぞれ推奨アプローチを紹介します。

まず、図 3 の GDI+ Graphics クラスを切り取り、Direct2D DC レンダーターゲットに置き換えます。これは、GDI に多くの投資を行ったアプリケーションがある場合は役立ちますが、最も効果的な解決策というわけではありません。Direct2D は、DC に直接レンダリングするのではなく、最初に内部の WIC ビットマップにレンダリングした後、その結果を DC にコピーします。これは、GDI+ よりも処理時間が短くなりますが、それでも、レンダリングに DC を使用しなければ必要のない余分なコピーが伴います。

この方法を使用するには、まず、D2D1_RENDER_TARGET_PROPERTIES 構造体を初期化します。これにより、Direct2D には、そのレンダーターゲットに使用するビットマップの形式が指示されます。これはプリマルチプライ済み BGRA ピクセル形式だったことを思い出してください。これは、D2D1_PIXEL_FORMAT 構造体で表現され、次のように定義できます。

const D2D1_PIXEL_FORMAT format = 
  D2D1::PixelFormat(DXGI_FORMAT_B8G8R8A8_UNORM,
  D2D1_ALPHA_MODE_PREMULTIPLIED);

const D2D1_RENDER_TARGET_PROPERTIES properties = 
  D2D1::RenderTargetProperties(
  D2D1_RENDER_TARGET_TYPE_DEFAULT,
  format);

これで、Direct2D ファクトリオブジェクトを使用して、DC レンダーターゲットを作成できるようになりました。

CComPtr<ID2D1DCRenderTarget> target;

Verify(factory->CreateDCRenderTarget(
  &properties,
  &target));

最後に、レンダーターゲットに対して、その描画コマンドの送信先となる DC を指示する必要があります。

const RECT rect = {0, 0, bitmap.GetWidth(), bitmap.GetHeight()};

Verify(target->BindDC(bitmap.GetDC(), &rect));

これで、BeginDraw メソッド呼び出しと EndDraw メソッド呼び出しの間で通常どおりに Direct2D を使って描画した後、これまでのように、ビットマップの DC を使用して Update メソッドを呼び出すことができます。EndDraw メソッドでは、すべての描画がバインドされた DC にフラッシュされるようにします。

Direct2D と WIC

GDI DC をまったく使用しないで、WIC ビットマップを直接使用できるようになると、ハードウェアアクセラレーションを使用しなくても、最高のパフォーマンスを実現することができます。この方法を使用するには、まず、WIC を使用して、直接、プリマルチプライ処理済みの BGRA ビットマップを作成します。

CComPtr<IWICImagingFactory> factory;
Verify(factory.CoCreateInstance(
  CLSID_WICImagingFactory));

CComPtr<IWICBitmap> bitmap;

Verify(factory->CreateBitmap(
  m_info.GetWidth(),
  m_info.GetHeight(),
  GUID_WICPixelFormat32bppPBGRA,
  WICBitmapCacheOnLoad,
  &bitmap));

次に、以前と同じように、D2D1_RENDER_TARGET_PROPERTIES 構造体を初期化する必要があります。ただし、レンダーターゲットと GDI に互換性が必要であることを Direct2D に指示することも必要です。

const D2D1_PIXEL_FORMAT format = 
  D2D1::PixelFormat(
  DXGI_FORMAT_B8G8R8A8_UNORM,
  D2D1_ALPHA_MODE_PREMULTIPLIED);

const D2D1_RENDER_TARGET_PROPERTIES properties = 
  D2D1::RenderTargetProperties(
  D2D1_RENDER_TARGET_TYPE_DEFAULT,
  format,
  0.0f, // default dpi
  0.0f, // default dpi
  D2D1_RENDER_TARGET_USAGE_GDI_COMPATIBLE);

これで、Direct2D ファクトリオブジェクトを使用して、WIC レンダーターゲットを作成できるようになりました。

CComPtr<ID2D1RenderTarget> target;

Verify(factory->CreateWicBitmapRenderTarget(
  bitmap,
  properties,
  &target));

ところで、D2D1_RENDER_TARGET_USAGE_GDI_COMPATIBLE は正確にはどのような処理を行っているのでしょう。これは ID2D1GdiInteropRenderTarget インターフェイスにレンダーターゲットを照会することを Direct2D に示唆しています。

CComPtr<ID2D1GdiInteropRenderTarget> interopTarget;
Verify(target.QueryInterface(&interopTarget));

実装の簡素化と効率化のため、このインターフェイスの照会は常に成功します。ただし、前もって目的のインターフェイスを指定しなかった場合に使用を試みたときのみ、失敗します。

ID2D1GdiInteropRenderTarget インターフェイスには、GetDC と ReleaseDC という 2 つのメソッドしかありません。ハードウェアアクセラレーションを使用するケースを最大限に活用するために、これらのメソッドの使用は、ターゲットの BeginDraw メソッドと EndDraw メソッドの呼び出しの間に制限されます。GetDC は、DC を返す前にレンダーターゲットをフラッシュします。相互運用インターフェイスのメソッドは対になっている必要があるため、図 7 に示すように、C++ クラスでラップすることが理にかなっています。

図 7 レンダーターゲットの DC ラッパークラス

class RenderTargetDC {
  ID2D1GdiInteropRenderTarget* m_renderTarget;
  HDC m_dc;

public:
  RenderTargetDC(ID2D1GdiInteropRenderTarget* renderTarget) :
    m_renderTarget(renderTarget),
    m_dc(0) {

    Verify(m_renderTarget->GetDC(
      D2D1_DC_INITIALIZE_MODE_COPY,
      &m_dc));

  }

  ~RenderTargetDC() {
    RECT rect = {};
    m_renderTarget->ReleaseDC(&rect);
  }

  operator HDC() const {
    return m_dc;
  }
};

これで、ウィンドウの Render メソッドは、図 8 に示すように、RenderTargetDC を使用するよう更新できます。この方法の優れている点は、WIC レンダーターゲットの作成に固有のすべてのコードが CreateDeviceResources メソッドに収容されていることです。次に、Direct3D レンダーターゲットを作成してハードウェアアクセラレーションを使用する方法について説明しますが、いずれにしても、図 8 の Render メソッドはそのまま変わりません。これにより、アプリケーションは、描画コードをまったく変更することなく、レンダーターゲットの実装を非常に簡単に切り替えることができるようになります。

図 8 GDI と互換性のある Render メソッド

void Render() {
  CreateDeviceResources();
  m_target->BeginDraw();
  // Do some drawing here
  {
    RenderTargetDC dc(m_interopTarget);
    m_info.Update(m_hWnd, dc);
  }

  const HRESULT hr = m_target->EndDraw();

  if (D2DERR_RECREATE_TARGET == hr) {
    DiscardDeviceResources();
  }
  else {
    Verify(hr);
  }
}

Direct2D と Direct3D/DXGI

ハードウェアアクセラレータを使用したレンダリングを行うには、Direct3D を使用する必要があります。自動的にハードウェアアクセラレーションを使用することになる ID2D1HwndRenderTarget を使って HWND に直接レンダリングしていないため、自身で Direct3D デバイスを作成し、GDI 互換の結果が得られるように、基になる DirectX Graphics Infrastructure (DXGI) の全体像を把握する必要があります。

DXGI は、Direct3D より下のレイヤーに存在する比較的新しいサブシステムで、基になるハードウェアから Direct3D を抽象化し、相互運用性のシナリオに対して高いパフォーマンスのゲートウェイを提供します。また、Direct2D は、この新しい API を利用して、Direct3D の今後のバージョンへの移行を簡単にします。この方法を使用するには、まず、Direct3D ハードウェアデバイスを作成します。これは、レンダリングを実行する GPU を表すデバイスです。ここでは、Direct2D で現在必要とされているため、Direct3D 10.1 API を使用しています。

CComPtr<ID3D10Device1> device;

Verify(D3D10CreateDevice1(
  0, // adapter
  D3D10_DRIVER_TYPE_HARDWARE,
  0, // reserved
  D3D10_CREATE_DEVICE_BGRA_SUPPORT,
  D3D10_FEATURE_LEVEL_10_0,
  D3D10_1_SDK_VERSION,
  &device));

D3D10_CREATE_DEVICE_BGRA_SUPPORT フラグは Direct2D 相互運用性にとって非常に重要です。BGRA ピクセル形式はそろそろ見慣れてきたでしょう。従来の Direct3D アプリケーションでは、スワップチェーンを作成し、レンダリングするテクスチャとしてそのバックバッファーを取得した後、レンダリングされたウィンドウを表示します。Direct3D をレンダリングのみに使用して表示には使用しないため、テクスチャリソースを直接作成できます。テクスチャは、テクセルを格納するための Direct3D リソースです。テクセルは、Direct3D のピクセルに相当します。Direct3D には 1D、2D、および 3D のテクスチャが用意されていますが、必要なのは 2 D テクスチャだけです。これは、2D サーフェイスに密接にマップされます (図 9 参照)。

図 9 2D テクスチャ

D3D10_TEXTURE2D_DESC description = {};
description.ArraySize = 1;
description.BindFlags = 
  D3D10_BIND_RENDER_TARGET;
description.Format = 
  DXGI_FORMAT_B8G8R8A8_UNORM;
description.Width = GetWidth();
description.Height = GetHeight();
description.MipLevels = 1;
description.SampleDesc.Count = 1;
description.MiscFlags = 
  D3D10_RESOURCE_MISC_GDI_COMPATIBLE;

CComPtr<ID3D10Texture2D> texture;

Verify(device->CreateTexture2D(
  &description,
  0, // no initial data
  &texture));

D3D10_TEXTURE2D_DESC 構造体では、作成するテクスチャを記述します。D3D10_BIND_RENDER_TARGET 定数は、テクスチャが Direct3D パイプラインの出力バッファー、つまりレンダーターゲットとしてバインドされることを示します。DXGI_FORMAT_B8G8R8A8_UNORM 定数により、Direct3D は GDI に適切なピクセル形式を生成するようになります。最後に、D3D10_RESOURCE_MISC_GDI_COMPATIBLE 定数は、基になる DXGI サーフェイスに対して、レンダリングの結果を取得できる GDI DC を提供するように指示します。この Direct2D は、前のセクションで説明した ID2D1GdiInteropRenderTarget インターフェイスを通じて公開されます。

既に説明したように、Direct2D は、DXGI API を使用して Direct3D サーフェイスにレンダリングし、この API を Direct3D の特定のバージョンに関連付けることを回避できます。これは、Direct2D に渡す、Direct3D テクスチャの基になる DXGI サーフェイスインターフェイスを取得する必要があることを意味します。

CComPtr<IDXGISurface> surface;
Verify(texture.QueryInterface(&surface));

この時点で、Direct2D ファクトリオブジェクトを使用して、DXGI サーフェイスのレンダーターゲットを作成できます。

CComPtr<ID2D1RenderTarget> target;

Verify(factory->CreateDxgiSurfaceRenderTarget(
  surface,
  &properties,
  &target));

レンダーターゲットのプロパティは、前のセクションで説明したプロパティと同じです。適切なピクセル形式を使用して GDI 互換を要求することを忘れないでください。その後、ID2D1GdiInteropRenderTarget インターフェイスを照会し、図 8 と同じ Render メソッドを使用することができます。

これで完了です。ハードウェアアクセラレーションを使用してレイヤードウィンドウをレンダリングする場合は、Direct3D テクスチャを使用してください。それ以外の場合は、WIC ビットマップを使用してください。この 2 つの方法を使用すると、コピー回数を最小限に抑えて、最高のパフォーマンスを実現できます。

DirectX のブログ (blogs.msdn.com/directx) (英語)、特に Ben Constable が 2009 年 8 月に投稿したコンポーネント化と相互運用性に関する記事をぜひご覧ください。

Kenny Kerr は、Windows 向けのソフトウェア開発を専門にしているソフトウェア設計者です。また、Window Clippings (windowclippings.com) の作成者でもあります。連絡先は weblogs.asp.net/kennykerr (英語) です。

ご質問やご意見は mmwincpp@microsoft.com (英語のみ) までお送りください。

この記事のレビューに協力してくれた技術スタッフの Ben Constable と Mark Lawrence に心より感謝いたします。