New issue
Advanced search Search tips

Issue 800604 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Chrome
Pri: 2
Type: Bug



Sign in to add a comment

GPU Raster tile sizing should consider dsf scaling

Project Member Reported by ericrk@chromium.org, Jan 10 2018

Issue description

On certain device screens / device scale factors (DSF), we can end up with non-optimal tilings as GPU raster does not take DSF rounding into account when calculating tile width.

Consider a theoretical device with a screen resolution of 1502x2560 and a DSF of 3.5.

In this case, mobile content with 100% width would be sized as:
ceil(1502 / 3.5) = ceil(429.1...) = 430 DIPs

Because of the ceil operation, we've grown the content bounds slightly, and if we convert the content bounds back to device pixels (DPs) we get:

ceil(430 * 3.5) = 1505 DPs

Despite content being sized at 1505, GPU tile width is based on original viewport width (1502). With rounding, this can sometimes work out, but in this case we end up with a final GPU tile size of 1504.

Because the tile is narrower than the content, we end up using an entire extra tile to accommodate 1 column of pixels.

Instead, we should adjust the GPU tile size for the DSF rounding, avoiding this case.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Jan 10 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7db283d1d769d05e88b565d5b583980f3d2202aa

commit 7db283d1d769d05e88b565d5b583980f3d2202aa
Author: Eric Karl <ericrk@chromium.org>
Date: Wed Jan 10 21:35:18 2018

GPU raster tile size calculation should account for DSF rounding

On certain device screens / device scale factors (DSF), we can end up with non-optimal
tilings as GPU raster does not take DSF rounding into account when calculating tile width.

Consider a theoretical device with a screen resolution of 1502x2560 and a DSF of 3.5.

In this case, mobile content with 100% width would be sized as:
ceil(1502 / 3.5) = ceil(429.1...) = 430 DIPs

Because of the ceil operation, we've grown the content bounds slightly, and if we convert
the content bounds back to device pixels (DPs) we get:

ceil(430 * 3.5) = 1505 DPs

Despite content being sized at 1505, GPU tile width is based on original viewport width
(1502). With rounding, this can sometimes work out, but in this case we end up with a
final GPU tile size of 1504.

Because the tile is narrower than the content, we end up using an entire extra tile to
accommodate 1 column of pixels.

Instead, we should adjust the GPU tile size for the DSF rounding, avoiding this case.

R=vmpstr

Bug:  800604 ,  792452 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: Ia39025374d3d30ebbf5e59508353648524f627f5
Reviewed-on: https://chromium-review.googlesource.com/858483
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528431}
[modify] https://crrev.com/7db283d1d769d05e88b565d5b583980f3d2202aa/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/7db283d1d769d05e88b565d5b583980f3d2202aa/cc/layers/picture_layer_impl_unittest.cc

Comment 2 by ericrk@chromium.org, Jan 10 2018

Status: Fixed (was: Started)

Sign in to add a comment