Chrome DevToolsの[レンダリング]には、[潜在的なスクロールのボトルネックを表示する]オプションがあります。
これを有効にすると、画面上にあるdiv
要素のoverflow:scroll
上部に「スクロール時に再描画」というフラグを表示します。
この機能に関する多くのドキュメントを見つけることができず、それが実際に修正または改善できるものなのか、それとも単なる事実の声明なのかわかりません-divにはコンテンツがあり、実際にスクロールします。
このCSSをdiv
に適用するには、overflow: scroll
またはoverflow: auto
スクロールのボトルネックを作成します。
transform: translateZ(0);
-webkit-transform: translateZ(0);
これにより、ブラウザーはこの要素をペイントするための新しいレイヤーを作成し、スクロールのボトルネックを修正することがあります(特にWebkitの場合)。
受け入れられた答えは問題を解決しますが、CSS _will-change
_ プロパティを見る価値があります。これは最近のtransform: translateZ(0);
よりも好まれています。ここにその違いが詳細に説明されている記事があります- https://dev.opera.com/articles/css-will-change-property/
_.scroll-container {
will-change: transform;
}
_
驚いたことに、何が起こっているのかを追跡するのに数日かかりましたが、それは Chromium bugtracker Issue 5143 のバグレポートの最後に1つのサイドコメントがあったからです。進行中の問題とその修正方法は次のとおりです。
「LCDテキスト」と呼ばれる概念が存在します。これは、サブピクセルアンチエイリアシング、つまり「鮮明なシャープテキスト」を意味すると考えています。残念ながら、この機能はコンポジターで加速されるスクロールと相互に互換性がありません。
LCDテキストは、高DPIではないすべてのプラットフォーム(ほとんどの通常のモニター。つまり、console.log(devicePixelRatio)
を確認できます)で、デフォルトで(少なくともBlink/Webkitで?)有効になっています。一方、LCDテキストはデフォルトでは、DPIの高いデバイス(Retinaディスプレイ、またはほとんどのモバイルデバイスとタブレットを考えてください)では無効になっています。高DPIプラットフォームの機能。
したがって、コンポジターアクセラレーションスクロールの場合は反対です。LCDテキストが無効になっている高DPIプラットフォームでのみ可能です。
ただし、ほとんどのモニターでoverflow:scroll
要素を独自のレイヤーに昇格させるか、その要素にwill-change:transform
を追加するか、オーバーフロー要素を独自のレイヤーの親にする強制的なハック同等物のいずれかによって、コンポジターで加速されたスクロールを強制できますtransform:translateZ(0)
)として。 (ベンダープレフィックスが削除されていることに注意してください。)
tl; dr:Chromeは、サブピクセルアンチエイリアスとgpuアシストスクロールの両方を想定していません。どちらかを選択します。サブピクセルアンチエイリアスは、Chrome (携帯電話とRetinaディスプレイは例外です。テキストは非常に小さいため、この機能は必要ありません。そのため、これらのプラットフォームではこの問題に気付かないでしょう。)will-change:transform
で要素を独自のコンポジターレイヤーに強制することでこれをオーバーライドします(ただし、テキストが完璧に見えないかもしれないことに注意してください)。