cc: When the transform's scale is unknown, draw render surfaces at the resolution of the screen.

cc: When the transform's scale is unknown, draw into render surfaces at the scale of the screen.

When the transform's scale is not known, we have to use some fixed value. We
were using 1.0 but this means if the transform is close to the identity, the
layers in the surface are rendered small, and then scaled up when the surface
is drawn to the screen by the device scale factor and page scale factor. This
makes for fuzziness.

So, when the transform's scale is not known we should use the device scale
and page scale factors as the default value. This guarantees that the transforms
from the contents of the surface's subtree to the screen will not require
scaling up more than any CSS scales specified by the HTML.

Tests:
LayerTreeHostCommonTest.verifySurfaceLayerTransformsInHighDPI

BUG=167021
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=174327

[enne (OOO), 2012-12-20 19:43:36]

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc
File cc/layer_tree_host_common.cc (right):

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc#...
cc/layer_tree_host_common.cc:393: gfx::Vector2dF transformScale =
MathUtil::computeTransform2dScaleComponents(combinedTransform, 1.f);
This is 1, because the contents scaling layers will automatically take into
account the device scale?

[danakj, 2012-12-20 22:42:30]

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc
File cc/layer_tree_host_common.cc (right):

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc#...
cc/layer_tree_host_common.cc:393: gfx::Vector2dF transformScale =
MathUtil::computeTransform2dScaleComponents(combinedTransform, 1.f);
On 2012/12/20 19:43:36, enne wrote:
> This is 1, because the contents scaling layers will automatically take into
> account the device scale?

This is 1 because we multiply by device scale factor and (sometimes) pagescale
factor down below on line 406.

It's choosing the "rasterScale" here, not the final "contentsScale"

[enne (OOO), 2012-12-20 23:18:48]

lgtm

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc
File cc/layer_tree_host_common.cc (right):

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc#...
cc/layer_tree_host_common.cc:393: gfx::Vector2dF transformScale =
MathUtil::computeTransform2dScaleComponents(combinedTransform, 1.f);
On 2012/12/20 22:42:30, danakj wrote:
> On 2012/12/20 19:43:36, enne wrote:
> > This is 1, because the contents scaling layers will automatically take into
> > account the device scale?
> 
> This is 1 because we multiply by device scale factor and (sometimes) pagescale
> factor down below on line 406.
> 
> It's choosing the "rasterScale" here, not the final "contentsScale"

True.  If you pick 1, then rasterScale = 1 / DSF or 1 / (DSF*PSF) but you happen
to clamp to 1 before using it, meaning that contents scale = 1 * DSF (and maybe
* PSF).  I guess that works out, but it seems a little magical.

[danakj, 2012-12-20 23:20:57]

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc
File cc/layer_tree_host_common.cc (right):

https://codereview.chromium.org/11635037/diff/1/cc/layer_tree_host_common.cc#...
cc/layer_tree_host_common.cc:393: gfx::Vector2dF transformScale =
MathUtil::computeTransform2dScaleComponents(combinedTransform, 1.f);
On 2012/12/20 23:18:48, enne wrote:
> On 2012/12/20 22:42:30, danakj wrote:
> > On 2012/12/20 19:43:36, enne wrote:
> > > This is 1, because the contents scaling layers will automatically take
into
> > > account the device scale?
> > 
> > This is 1 because we multiply by device scale factor and (sometimes)
pagescale
> > factor down below on line 406.
> > 
> > It's choosing the "rasterScale" here, not the final "contentsScale"
> 
> True.  If you pick 1, then rasterScale = 1 / DSF or 1 / (DSF*PSF) but you
happen
> to clamp to 1 before using it, meaning that contents scale = 1 * DSF (and
maybe
> * PSF).  I guess that works out, but it seems a little magical.

The reason we do it this way, and it's so different from the rendersurface case
which is much simpler is:

- This is main thread only.
- This computed value is saved permanently on the layer as the rasterScale.
- This value is then combined with the page and device scale factors in every
future iteration to form the current contentsScale.

Whereas the rendersurface one is both threads (but really affects impl) and is a
throwaway value, used only for the current frame.

[commit-bot: I haz the power, 2012-12-20 23:23:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/11635037/1

[danakj, 2012-12-20 23:27:12]

https://chromiumcodereview.appspot.com/11635037/diff/11003/cc/layer_tree_host...
File cc/layer_tree_host_common.cc (right):

https://chromiumcodereview.appspot.com/11635037/diff/11003/cc/layer_tree_host...
cc/layer_tree_host_common.cc:393: gfx::Vector2dF transformScale =
MathUtil::computeTransform2dScaleComponents(combinedTransform, 0.f);
Now switch to 0.f so we don't save it when we don't know the scale. Thanks :)

[commit-bot: I haz the power, 2012-12-20 23:27:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/11635037/11003

[commit-bot: I haz the power, 2012-12-21 02:59:14]

Change committed as 174327