フォームのちらつき（フリッカー）を根絶する：DoubleBufferedプロパティとカスタム描画最適化の全知識
Windows Forms（WinForms）アプリケーションの寿命は長い。VB6やVBAの時代から連綿と続く業務システムの改修現場において、いまだに現役で稼働し続けるVB.NET製クライアントアプリケーションは数多く存在する。
特に、多数のカスタムコントロールを配置した画面や、独自のグリッド、チャート、ダッシュボードを描画する画面において、避けて通れないのが「画面のちらつき（フリッカー）」という悪夢だ。
ユーザーがウィンドウをリサイズした瞬間、あるいはタイマーやバックグラウンド処理に伴って再描画が発生するたびに、画面が白く点滅する。この現象は単なる美観の問題ではない。長時間画面に向かうオペレーターの眼精疲労を増大させ、システム全体の「安っぽさ」「動作の重さ」を直感させる致命的なUXの欠陥である。
本稿では、このフリッカー現象の根本原因であるGDI/GDI+の描画メカニズムを解剖し、`DoubleBuffered`プロパティの真の挙動、そしてWindows API（Win32 API）を直接叩いたカスタム描画最適化の極限の知見を、伝説的アーキテクトの視点から授ける。
—
1. なぜフリッカー（ちらつき）が発生するのか？ —— 描画の裏側を暴く
フリッカーの根源は、Windowsの標準的なウィンドウ描画プロセスにある。
何も対策をしていないコントロールやフォームに対して再描画要求（`Invalidate`など）が発生すると、OSは以下のプロセスを遂行する。
1. Erase（消去フェーズ）: `WM_ERASEBKGND` メッセージが発行され、ウィンドウの背景（通常はコントロールの `BackColor`）で描画領域全体が一度「単色（多くは白）」で塗りつぶされる。
2. Paint（描画フェーズ）: `WM_PAINT` メッセージが発行され、実際のコントロールの形状、テキスト、イメージがその上から上書きされる。
この「一度消して、描画する」という2段階のステップが、人間の目で知覚できるほどの時間差（あるいはリフレッシュレートのタイミングのズレ）を生むとき、ユーザーには背景の「白（消去）」がチラリと見えてしまう。これがフリッカーの正体である。
特に、レイアウトが複雑で子コントロールが多いフォームや、毎フレーム計算を伴うカスタム描画を行っている場合、この消去と描画の競合が顕著になり、画面全体が激しく点滅する。
—
2. DoubleBufferedプロパティの光と影
この問題を解決する最も手軽な手段が、ダブルバッファリング（二重バッファ）である。
VB.NETの `Form` や `Control` クラスには、標準で `DoubleBuffered` プロパティが用意されている。これを `True` に設定するだけで、描画は一度画面上の見えないメモリバッファ（オンスクリーンではなくオフスクリーン・ビットマップ）上で行われ、完成した完璧な画像が一瞬で画面に転送（Blt）されるため、消去フェーズの白パカが完全に隠蔽される。
しかし、ここでシニアエンジニアが知るべき重要な事実がある。
`Control` クラスの `DoubleBuffered` プロパティは、デフォルトでは `Protected` であり、外部から直接 `.DoubleBuffered = True` と叩けない場合があるということだ（特にカスタムコントロールを作成している場合）。
さらに、フォーム全体でこれを有効にするには、内部のスタイルフラグを適切に立てる必要がある。
フォームおよびコントロールでのダブルバッファ有効化の実装
以下のコードは、フォームのコンストラクタ、あるいはカスタムコントロールの初期化時に実行すべき、最も確実なスタイル設定のイディオムである。
Imports System.Windows.Forms
Imports System.Runtime.InteropServices
Public Class OptimizedForm
Inherits Form
Public Sub New()
‘ 1. コントロールのスタイルを直接変更し、ダブルバッファと最適化を強制適用する
‘ ControlStyles.DoubleBuffer: 描画をバッファ経由にする
‘ ControlStyles.AllPaintingInWmPaint: WM_ERASEBKGND（背景消去メッセージ）を無視し、WM_PAINT内で一括描画する
‘ ControlStyles.UserPaint: コントロール自身が描画を行うことをOSに伝える
Me.SetStyle(ControlStyles.DoubleBuffer Or _
ControlStyles.AllPaintingInWmPaint Or _
ControlStyles.UserPaint Or _
ControlStyles.OptimizedDoubleBuffer, True)
‘ 2. スタイルの変更をコントロールに即時反映させる
Me.UpdateStyles()
End Sub
End Class
> アーキテクトの知見:
> 単に `DoubleBuffered = True` と記述するだけでは不十分なケースが多い。特に `AllPaintingInWmPaint` を同時に立てることが極めて重要である。これにより、無駄な `WM_ERASEBKGND` の処理がバイパスされ、背景のちらつきの元凶が断ち切られる。
—
3. Win32 APIとメッセージフックによる描画の極限最適化
標準のマネージドコードによるダブルバッファリングでさえ、極端に重い描画処理（何千ものベクター要素を描画するCAD風UIや、リアルタイムの株価チャートなど）の前には力尽きることがある。
ここで、GDIの底流にあるWin32 APIを直接操作し、メッセージループレベルで描画を制御する手法が必要となる。`.NET Framework` / `.NET Core` の抽象化層をあえて一枚剥ぎ取り、OSと直接対話するのだ。
制御の要：`WM_SETREDRAW` による描画の一時停止
フォームに対して大量の子コントロールを一括追加・更新する際、コントロールが1つ追加されるたびに再描画走査が走り、凄まじいフリッカーとパフォーマンス低下を引き起こす。これを防ぐためには、更新処理の前後でOSの描画メッセージをロックするのが定石である。
以下のモジュールは、Win32 APIの `SendMessage` を利用して、ウィンドウの描画を完全に凍結・解凍するテクニックだ。
Imports System.Runtime.InteropServices
Public NotInheritable Class DrawingOptimizer
‘ Win32 APIの定義
Private Shared Function SendMessage(hWnd As IntPtr, wMsg As Integer, wParam As IntPtr, lParam As IntPtr) As IntPtr
End Function
Private Const WM_SETREDRAW As Integer = &HB
”’
”’
Public Shared Sub SuspendDrawing(ctrl As Control)
If ctrl Is Nothing OrElse Not ctrl.IsHandleCreated Then Return
SendMessage(ctrl.Handle, WM_SETREDRAW, IntPtr.Zero, IntPtr.Zero)
End Sub
”’
”’
Public Shared Sub ResumeDrawing(ctrl As Control, refreshNow As Boolean)
If ctrl Is Nothing OrElse Not ctrl.IsHandleCreated Then Return
‘ 再描画フラグをONに戻す
SendMessage(ctrl.Handle, WM_SETREDRAW, New IntPtr(1), IntPtr.Zero)
If refreshNow Then
ctrl.Invalidate(True) ‘ 子コントロールも含めて無効領域を設定
ctrl.Update() ‘ 即座にWM_PAINTを発行
End If
End Sub
End Class
実際の業務画面での適用パターン
この `DrawingOptimizer` は、例えば大量の行を持つ `DataGridView` やカスタムパネルを動的に構築・再描画する際に絶大な効果を発揮する。
‘ 大量のコントロール追加・レイアウト変更前
DrawingOptimizer.SuspendDrawing(Me)
Try
‘ — ここに重いコントロールの追加やプロパティ変更処理を記述 —
For i As Integer = 1 to 1000
Dim panel As New Panel()
‘ プロパティ設定…
Me.PanelContainer.Controls.Add(panel)
Next
Finally
‘ 処理完了後、一瞬で描画を再開し、画面を更新
DrawingOptimizer.ResumeDrawing(Me, True)
End Try
これにより、コントロールが1つずつ泥臭く描画されていく過程がユーザーの目に触れることは一切なくなり、あたかも一瞬で画面が構築されたかのようなプロフェッショナルな挙動を実現できる。
—
4. メモリ管理の鉄則：GDIリソースの枯渇を防ぐ
カスタム描画やダブルバッファリングを実装する際、VB.NETプログラマが最も陥りやすい罠が GDIリソース（ハンドル）のリーク である。
マネージドな `Bitmap` や `Graphics` オブジェクトはGC（ガベージコレクション）の管理下にあるが、内部で保持しているGDIのネイティブハンドル（HBITMAP, HDCなど）は、適切なタイミングで破棄（Dispose）されないと、Windows全体のシステムリソースを食潰し、やがて「HBITMAPを作成できません」という致命的な例外や、最悪の場合はOS全体の描画崩壊を引き起こす。
危険なコードの例（アンチパターン）
‘ 【絶対にやってはいけない例】
Private Sub Form_Paint(sender As Object, e As PaintEventArgs) Handles MyBase.Paint
‘ 毎回の描画イベントのたびにビットマップを新規生成し、Disposeしていない、あるいはGC任せにしている
Dim bmp As New Bitmap(Me.Width, Me.Height)
Dim g As Graphics = Graphics.FromImage(bmp)
‘ 描画処理…
e.Graphics.DrawImage(bmp, 0, 0)
‘ g と bmp が破棄されないままイベントが終了する！
End Sub
正しいリソース管理のイディオム（Using構文の徹底）
カスタム描画を行うオーバーライドメソッド（`OnPaint`など）では、必ず `Using` 構文を使用し、ネイティブ・リソースをそのスコープ内で確実に解放しなければならない。
Protected Overrides Sub OnPaint(e As PaintEventArgs)
‘ ちらつきのないカスタム描画の模範実装
‘ 描画先のクライアント領域を取得
Dim rc As Rectangle = Me.ClientRectangle
If rc.Width <= 0 OrElse rc.Height <= 0 Then Return
' オフスクリーン・バッファを生成（Usingによりスコープ離脱時に必ずDisposeされる）
Using offscreenBitmap As New Bitmap(rc.Width, rc.Height, e.Graphics)
Using offscreenGraphics As Graphics = Graphics.FromImage(offscreenBitmap)
' 背景をクリア
offscreenGraphics.Clear(Me.BackColor)
' --- ここに実際の描画ロジックを記述（高速化のためアンチエイリアス設定等もここで） ---
offscreenGraphics.SmoothingMode = Drawing2D.SmoothingMode.AntiAlias
Using pen As New Pen(Color.FromArgb(0, 120, 215), 2)
offscreenGraphics.DrawRectangle(pen, 10, 10, rc.Width - 20, rc.Height - 20)
End Using
' ----------------------------------------------------------------------------------
' 完成したバッファを一気に画面のGraphicsへ転送（Blt）
e.Graphics.DrawImage(offscreenBitmap, rc.Location)
End Using
End Using
' MyBase.OnPaint(e) は、背景の二重描画を防ぐため、カスタム描画時はあえて呼ばないか、
' または描画ロジックの性質に応じて適切に制御する。
End Sub
---
5. レガシーシステム保守・移行における最終チェックリスト
長年運用されてきたVB.NETアプリケーションのパフォーマンスチューニングを任されたアーキテクトへ、現場で即座に確認すべきチェックリストを贈る。
1. `DoubleBuffered = True` の適用漏れはないか？
- ユーザーコントロール、カスタムパネル、グリッドの親フォームに至るまで、階層構造全体のコントロールでダブルバッファが有効になっているか確認せよ。
2. 無駄な `Refresh()` の連打をしていないか？
- コード内のあちこちに `Me.Refresh()` が散らばっている場合、それは強制的な即時再描画を引き起こし、フリッカーの最大の原因となる。`Me.Refresh()` を `Me.Invalidate()` に置き換え、OSに描画スケジュールを委ねる設計へリファクタリングせよ。
3. 高DPI環境（ハイレゾディスプレイ）でのスケーリングバグはないか？
- ダブルバッファ用のBitmapを生成する際、物理ピクセルと論理ピクセル（DPIスケーリング）の計算を誤ると、拡大時に描画領域がズレたり、端が切れる現象が発生する。`e.Graphics.DpiX` や `DeviceDpi` を考慮したバッファサイズ計算を行っているか確認せよ。
4. 不要な背景色設定（`BackColor` の明示的指定）がちらつきを誘発していないか？
- コントロールの背景色と親の背景色が一致していない場合、消去フェーズで不一致の矩形が露出してちらつきが強調される。透過処理（`BackColor = Color.Transparent`）の多用は描画負荷を数倍に跳ね上げるため、静的な背景では極力避けるべきである。
—
結び
フォームのちらつき（フリッカー）は、単なる「古い技術の仕様」として諦めるべきものではない。
OSの描画パイプライン（`WM_ERASEBKGND` と `WM_PAINT`）のメカニズムを正しく理解し、適切なスタイルの設定、Win32 APIによる描画の抑止、そして厳格なGDIリソースのライフサイクル管理を行うことで、レガシーなWindows Formsアプリケーションであっても、モダンで滑らかなUI体験を完全に再現することが可能である。
技術の本質を知る者にとって、コントロールの1ピクセルの動きすら、完全な制御下に置くべき対象なのだ。あなたの手元のコードベースから、すべての「ちらつき」を根絶せよ。
