アンチエイリアスとサブピクセルレンダリング、devicePixelRatio

「ぼやける」「1pxが消える」の正体は同じ1本の軸

高解像度ディスプレイで起きる代表的な悩み、画像がぼやける・Canvasの線が眠い・1pxボーダーが細すぎる/消えるは、見た目はバラバラでも原因は1本の軸に集約できます。それは「CSSが書く座標の単位」と「画面が光らせる素子の単位」が一致していないことです。前者を論理ピクセル（CSSピクセル）、後者を物理ピクセル（デバイスピクセル）と呼び、両者の比を devicePixelRatio（DPR）が表します。本稿はこの2つの座標系の対応関係を土台に、画像とCanvasを鮮明に描く方法、そして1pxボーダー問題の発生機構を内部動作から整理します。ペイントとラスタライズが描画全体のどこに位置するかは ブラウザのピクセルパイプライン図解 を合わせて押さえてください。

論理ピクセルと物理ピクセル、そしてDPR

devicePixelRatio は 物理ピクセル数 ÷ 論理ピクセル数 です。値が2なら、CSS上の 1px は画面上では縦2個・横2個の計4個の物理ピクセルとして描かれます。なぜこんな段差が要るのかというと、画素密度が上がった画面でCSSの 1px をそのまま1物理ピクセルに割り当てると、文字もボタンも物理的に小さくなりすぎて読めなくなるからです。そこでOS/ブラウザは論理ピクセルを「だいたい一定の見かけ角サイズ」に保つ基準として定義し、密度の余剰をDPRという倍率に吸収させます。

注意したいのは、DPRは整数とは限らないことです。多くのスマートフォンは2.625や3など端数や3倍を取り、ブラウザのズーム操作でも値が動きます（ズーム150%はDPRに乗算的に効きます）。さらにDPRは実行中に変化しうる点も重要です。ウィンドウを別密度のモニタへドラッグした、ユーザーがズームした、といった場面で値が変わるため、一度読んだ値をキャッシュしっぱなしにすると描画解像度がずれます。

// DPRの変化を監視する。ズームやモニタ移動で発火する
function onDprChange(cb) {
  const mql = matchMedia(`(resolution: ${devicePixelRatio}dppx)`);
  mql.addEventListener("change", () => {
    cb(devicePixelRatio);
    onDprChange(cb); // 新しいDPRで張り直す（クエリ値が固定のため）
  }, { once: true });
}

アンチエイリアスとサブピクセルの分配

ラスタライザは、図形の輪郭が物理ピクセルの格子の途中を通るとき、その素子を中間的な濃さで塗ります。これがアンチエイリアスです。たとえば斜め線や曲線がピクセル境界をまたぐと、被覆率（その素子を図形がどれだけ覆うか）に応じてアルファを按分し、階段状のギザギザを目立たなくします。鮮明さの議論はすべて「輪郭が物理格子に乗るか、途中を通るか」に帰着します。

ここで紛らわしいのが「サブピクセル」という語の二義性です。実務で問題になるのは主に前者です。

LCDサブピクセルレンダリング（ClearType等）は1つの物理ピクセルを構成するR・G・Bの帯を個別の濃淡素子とみなし、文字の横解像度を実効3倍にしてにじみを抑える手法です。ただし配列がRGB前提のため画面回転や非標準パネルで色割れし、近年は高DPI化で恩恵が薄れ、要素にtransformが掛かると無効化されることもあります。一方、幾何的なサブピクセル位置のずれはDPRに関わらず常に存在し、こちらが画像・Canvas・1px問題の主役です。

画像とCanvasの鮮明化

画像がぼやける機構は単純です。DPRが2の画面に幅360CSS pxで表示する画像は、物理的には720素子分の面を占めます。ここへ360画素しか持たない画像を流し込むと、ブラウザは1ソース画素を2素子へ引き伸ばし（バイリニア補間など）、結果として輪郭が複数素子へにじみます。解決は「物理ピクセル数に見合うソース画素を渡す」一点です。<img> では srcset の x記述子で密度別の素材を用意し、ブラウザにDPRで選ばせます。

<!-- DPRに応じてソースを選ばせる。2xは横720画素相当の素材 -->
<img src="logo.png"
     srcset="logo.png 1x, logo@2x.png 2x, logo@3x.png 3x"
     width="360" alt="ロゴ">

レイアウト上の表示サイズ（ここでは width="360"）は論理ピクセルのまま据え置き、素材の中身だけを高密度化するのが要点です。表示幅とソース解像度を混同して箱まで大きくしてしまうと崩れます。CLSを避ける比率予約や loading/decoding の使い分けは 画像のデコードとレンダリング に、srcset/sizes を含む幅可変の作法は レスポンシブデザイン に分けてあります。

Canvasはさらに明示的な対処が要ります。Canvasにはバッキングストア（実際に画素を持つ内部ビットマップ。canvas.width/height）と表示サイズ（CSSの幅高）の2つがあり、両者がずれると拡大縮小が起きます。既定では canvas.width=300 を360CSS pxへ伸ばせばぼやけ、DPR=2なら本来720素子必要な面を300画素で埋めることになります。定石はバッキングストアをCSSサイズのDPR倍に取り、描画コンテキストをDPRでスケールして、座標は論理ピクセルのまま書けるようにする方法です。

function setupHiDPICanvas(canvas, cssW, cssH) {
  const dpr = window.devicePixelRatio || 1;
  // 内部解像度は物理ピクセルに合わせる
  canvas.width = Math.round(cssW * dpr);
  canvas.height = Math.round(cssH * dpr);
  // 見かけのサイズは論理ピクセルで固定
  canvas.style.width = cssW + "px";
  canvas.style.height = cssH + "px";
  const ctx = canvas.getContext("2d");
  // 以降は論理ピクセル座標で描けば物理解像度で出る
  ctx.scale(dpr, dpr);
  return ctx;
}

1pxボーダー問題の発生機構

Retina系で「1pxの線が細すぎる/かすれる」と言われる現象は、実は2つの異なる原因が混在しています。

1つ目はDPR起因の見た目の細さ。CSSの border: 1px はDPR=3の画面では3物理素子分の太さで描かれ、これは設計上正しいのですが、デザイナーが期待する「ヘアライン（物理1素子の極細線）」より太く見えることがあります。逆に物理1素子ぴったりを狙って 1px / dpr（DPR=3なら約0.333px）を指定すると、輪郭が物理格子の整数境界に乗らず、アンチエイリアスで隣接素子へ薄く分配され、かすれとして現れます。

2つ目は非整数座標起因のにじみ。これはDPRが1の環境でも起きます。要素の位置やサイズが小数CSS pxになると、線の中心が物理格子の整数境界からずれ、被覆率按分で線が2素子へ半分ずつ塗られ、結果として薄くぼけた2pxのように見えます。Canvasで ctx.lineWidth=1 の縦線を整数x座標に引くと、線は中心が境界に乗るため左右へ0.5ずつ広がり、まさにこの現象が出ます。回避には座標を0.5ずらす（中心を素子中央に置く）のが古典的定石です。

実務でヘアラインを安定させる定番は、疑似要素に通常の1pxボーダーを描き、transform: scale() でDPRの逆数に縮める手法です。スケール変換は合成段で効くため按分の事故が起きにくく、物理1素子に近い線を比較的安全に得られます。

/* DPR非依存で物理1px相当のヘアラインを狙う */
.hairline { position: relative; }
.hairline::after {
  content: "";
  position: absolute; inset: 0;
  border-bottom: 1px solid #ccc;
  transform: scaleY(0.5);          /* DPR=2想定。実際はメディアクエリで分岐 */
  transform-origin: bottom;
}
@media (min-resolution: 3dppx) {
  .hairline::after { transform: scaleY(0.3333); }
}

transformやscaleがなぜ合成段で安価に効くのか、どの操作がレイヤーを生むかは ブラウザのレイヤー化とGPUコンポジット を参照してください。

まとめ