デバイスピクセル比とは何ですか？

なぜ1つのCSSピクセルは1つのハードウェアピクセルではないのか

デバイスのピクセル比は、ブラウザが状態を公開したり、コンテンツをレンダリングしたり、自動化されたアクションが安全かどうかを決定する方法に影響を与えます。正確な定義は、チームが狭い信号を普遍的な回答と見なすのを防ぎます。また、期待されるブラウザの挙動が文書化されたライフサイクル、API、またはシステムの境界に結び付けられているため、テストの失敗が診断しやすくなります。

ウェブ自動化において、実際の質問は常に「ページは準備ができていますか？」や「ブラウザはリアルに見えますか？」よりも狭いものです。次のステップでは、一つのコントロールを有効にする必要があったり、ナビゲーションを完了させるために一つのフレームが必要だったり、内部ツリーを接続するために一つのコンポーネントが必要だったり、一つのレンダリングサーフェスが一貫性を保つ必要があったりします。以下のセクションでは、信仰に頼るのではなく、概念を観察可能なチェックに変換します。

コアデバイスピクセル比率の公式

デバイスピクセル比は、現在の表示環境における物理デバイスピクセルとCSSピクセルの比率です。比率が1の場合、1つのCSSピクセルは、簡略モデルで1つのデバイスピクセルに対応しています。比率が2の場合、CSSピクセルは2x2のデバイスピクセルのブロックに広がり、レンダラーにエッジ、テキスト、画像の物理サンプルをより多く提供します。

The MDN devicePixelRatio 参照 物理ピクセル解像度とCSSピクセル解像度の比率としてプロパティを定義します。ブラウザは、window.devicePixelRatioを通じて浮動小数点値としてこれを公開します。値は整数である必要はなく、オペレーティングシステムのスケーリングやページのズームによって小数の結果が生じることがあります。

CSSピクセルは論理的なレイアウト単位です。これは、非常に異なる物理密度の画面間でインターフェースを使いやすく保ちます。その抽象化がなければ、ハードウェアピクセルの固定数で説明されたボタンは、密度の高い電話のディスプレイで非常に小さくなる可能性があります。デバイスピクセル比は、論理座標系を利用可能なディスプレイサンプルに接続します。

CSSピクセル、デバイスピクセル、および解像度

画面解像度は通常、物理的なピクセルでの幅と高さとして説明されます。CSSビューポートサイズは論理ピクセルで説明されます。デバイスピクセル比がこれらを関連付けますが、ブラウザの外観、オペレーティングシステムのスケーリング、向き、および丸めにより、単純な掛け算では常にすべての画面値を正確に再現することはできません。

密度は物理的な長さあたりの物理ピクセル数であり、DPRはブラウザのスケーリング比率です。2つの画面は解像度を共有できますが、物理的なサイズが異なるため、密度も異なります。2つのブラウザも、異なる基盤密度を持つデバイスで同じDPRを示すことがあります。なぜなら、オペレーティングシステムが読みやすいUIに適したスケールを選択するからです。

ルール： 1. 翻訳されたテキストのみを出力します — 説明や余分なコードフェンスのラッピングは行いません。 2. Markdown/HTML構造（見出し、リスト、リンク、表）を正確に保持します。 3. @@CODEBLOCK_0@@ や @@INLINECODE_0@@ のようなプレースホルダートークンはそのままにします；決して翻訳、順序変更、統合、または再フォーマットしないでください。 4. ``` コードフェンスを追加したり削除したりすることはせず、通常のテキストをコードブロックにラッピングしないでください。 The CSSOM View の devicePixelRatio の定義 ブラウザがCSSピクセルサイズとデバイスピクセルサイズから値を導き出す方法を指定します。その基準フレームは、DPRをRetinaのようなマーケティングラベルとして扱うよりも正確です。これは、レンダリング環境が変化した時に変わる可能性があるランタイムブラウザ値です。

なぜZoomは画像を変更するのか

ページのズームは、デバイスピクセルに対するCSSピクセルのサイズを変更しますので、ユーザーがズームインまたはズームアウトする際にwindow.devicePixelRatioが変わる可能性があります。解像度メディアクエリの変更をリッスンしているページは、この遷移を観察することができます。また、異なるスケーリングを持つディスプレイ間でウィンドウを移動することも値を変更する可能性があります。

ピンチズームは異なります。それはレイアウトのCSSピクセルを同じ方法で再定義することなく、ユーザーのためにビジュアルビューポートを拡大します。したがって、レスポンシブレイアウトのブレークポイントは必ずしもページズームのように動作するわけではありません。ズームをテストする自動化は、それがブラウザのページズームを変更しているのか、デバイスのスケールファクターをエミュレートしているのか、またはビジュアルビューポートを操作しているのかを定義する必要があります。

フラクショナルDPRには注意が必要です。CSSサイズに比率を掛けると、整数でないビットマップの寸法が生成される可能性があります。キャンバスやスクリーンショットのロジックは、丸め戦略を選択する必要があり、グラフィックスコードはすべてのCSSエッジがデバイスピクセルの境界にきれいにマッピングされると仮定することを避けなければなりません。小さな丸めの違いは、ぼやけた線や1ピクセルの縫い目として現れることがあります。

キャンバス、画像、およびスクリーンショットにおけるDPR

キャンバスにはCSS表示サイズと内部ビットマップサイズがあります。高DPRディスプレイで両方が同じ数値の寸法を使用すると、ブラウザーは低解像度のビットマップをより多くのデバイスピクセルに伸ばすため、柔らかく見えることがあります。一つの一般的なアプローチは、ビットマップの寸法をDPRでスケーリングし、その後描画座標系をスケーリングすることで、アプリケーションコードが依然としてCSS単位を使用できるようにします。

画像には内在的なピクセル寸法とCSSレイアウト寸法もあります。レスポンシブ画像の選択では、密度記述子を使用してブラウザが現在の環境に適したアセットを選択できます。正しいCSSサイズ指定なしに大きなファイルを提供しても、レイアウトが自動的に改善されるわけではありません。それはレンダラーにより多くのソース詳細を提供するだけです。

自動化のスクリーンショットは、APIに応じてCSSピクセル、デバイスピクセル、またはツール特有の単位で寸法を報告することがあります。DPR二重コンテキストからのフルページスクリーンショットは、CSSページサイズが示すよりも著しく多くのビットマップピクセルを含むことがあります。テストのアサーションは、正しい座標空間を比較し、すべてのビジュアルベースラインでDPRを記録する必要があります。

デバイスピクセル比は指紋信号です。

DPRは、可能なデバイスとスケーリング構成のセットを狭めるため、ブラウザの指紋に寄与する可能性があります。単独では粗く広く共有されています。画面の幅、画面の高さ、ビューポート、色深度、タッチサポート、プラットフォーム、ユーザーエージェントと組み合わせることで、より情報量が増します。

その W3Cの指紋認識ガイダンス は、暴露されたエントロピーを最小限に抑え、信号がどのように組み合わさるかを考慮することを推奨しています。その組み合わせの原則は、DPRを単独で変更することが完全なデバイスエミュレーションではない理由を説明します。デスクトップビューポート、タッチポイントなし、および無関係なピクセル比を持つモバイルユーザーエージェントは、内部的に矛盾しています。

許可された自動化の場合は、一貫したセットとしてデバイスプロファイルを選択します。ビューポート、画面寸法、DPR、向き、入力機能、ロケール、ユーザーエージェントを一緒に定義します。セッション中はこれらを安定させておきます。目標がレスポンシブテストである場合は、実際のディスプレイが一般的に使用する任意の幅とDPRの組み合わせを生産するのではなく、名前付きプロファイルの小さなマトリックスをテストします。

レイアウトおよびビジュアルテストの問題をデバッグする

スクリーンショットが異なる場合は、最初にwindow.devicePixelRatio、ビューポートの寸法、画面の寸法、ページのズーム、およびスクリーンショットのビットマップサイズを記録します。違いがレイアウトの変更か、単にラスタライズの変更かを判断します。CSSボックスは、同じ論理サイズを占有しながら、そのエッジが異なる数の物理ピクセルを使用することがあります。

解像度、幅、ホバー、ポインタ機能を使用するメディアクエリを検査します。ページは、特定のDPRで異なる画像またはコンポーネントを読み込む場合があります。キャンバスのバックサイズおよびブラウザツールに渡されたデバイススケール設定を確認してください。任意の遅延を追加することで視覚の差異を修正しようとしないでください。タイミングは座標空間の不一致を修正しません。

視覚的ベースラインを名前付きブラウザビルドとデバイスプロファイルに固定します。ブラウザのテキストレンダリングはバージョンによって変わることがあるため、ピクセル完璧の等価性が実際の製品要件でない場合は、レビュー可能な許容差を許可します。レイアウトのアサーションには、CSSピクセルでDOM geometryを優先します。レンダリング品質については、スクリーンショットを使用し、証拠の一部としてDPRを保持します。

再現可能なディスプレイプロファイルの選択

タスクが進行できることを証明するために最小の条件または構成から始めます。標準互換のブラウザ動作を保持し、その後、ワークフローが必要とする場合にのみプロファイル制御を追加します。ブラウザビルドと関連する状態を記録し、後の違いを説明できるようにします。再現可能な観察は、ページ、フレーム、ディスプレイ、または指紋が単に「完了」または「安全」であるという広範な主張よりも有用です。

• 次のアクションを定義します。 スクリプトまたはユーザーが待機または構成ステップの後に何をする必要があるかを正確に述べます。
• 観察可能な信号を選択します。 そのアクションを直接サポートするブラウザのプロパティ、ライフサイクルの状態、要素の条件、またはレンダリング結果を優先します。
• 関連する値を一貫させます。 ブラウザ、オペレーティングシステム、画面、ロケール、グラフィックス、およびセッション設定は、一つの妥当な環境を描写する必要があります。
• 通常のアプリケーション動作を検証します。 プライバシーまたは自動化の介入は、変更されるAPIまたはコンポーネントを静かに破壊するべきではありません。
• 診断証拠をキャプチャします。 チェックが失敗した場合に関連するURL、状態、コンソールメッセージ、および構成名を保存します。

結論

デバイスピクセル比は、ブラウザのCSS座標システムを物理ディスプレイピクセルにリンクします。それはラスタ品質、キャンバスバックストレージ、レスポンシブアセット、スクリーンショット、および指紋の一貫性に影響を与えますが、解像度や物理的な密度の代わりにはなりません。信頼できる自動化は、ビューポートと画面設定でDPRを記録し、全体のデバイスプロファイルを一貫させます。

その Scrapeless Scraping Browserのドキュメント は、管理されたブラウザセッションがどのように構成されるかを説明し、 Scraping Browser製品概要 はブラウザ自動化の表面を説明します。これらのリソースは、許可されたワークフローで概念を適用するための製品コンテキストを提供します。

参考文献

• Scrapeless Scraping Browser 始め方のドキュメント
• Scrapeless Scraping Browser 製品概要
• Scrapeless キャンバス描画とフィンガープリンティングガイド
• GitHubのScrapelessオープンソースプロジェクト