Explicitly specify contents scale for SurfaceLayer.

Explicitly specify contents scale for SurfaceLayer.

The RWHVA changes the bounds of the layer on window resize, but the contents shouldn't be scaled to fit in that case, so specify an explicit scale when the surface id is set.

Committed: https://crrev.com/b71b07c2279f6c8b33aa65e8bf31aedcef35d750
Cr-Commit-Position: refs/heads/master@{#303950}

[jbauman, 2014-11-12 01:01:33]

jbauman@chromium.org changed reviewers:
+ jamesr@chromium.org, piman@chromium.org

[piman, 2014-11-12 02:36:58]

https://codereview.chromium.org/719573003/diff/1/ui/compositor/layer.cc
File ui/compositor/layer.cc (right):

https://codereview.chromium.org/719573003/diff/1/ui/compositor/layer.cc#newco...
ui/compositor/layer.cc:585: : 1.f;
Any reason we're not passing the renderer's DSF instead of recomputing it?

In the caller, frame_size_in_dip is computed explicitly from the frame_size
(surface_size) and the renderer's DSF. It seems it would avoid additional
precision issues for non-pow2 DSF.

[jbauman, 2014-11-12 02:49:45]

On 2014/11/12 02:36:58, piman (Very slow to review) wrote:
> https://codereview.chromium.org/719573003/diff/1/ui/compositor/layer.cc
> File ui/compositor/layer.cc (right):
> 
>
https://codereview.chromium.org/719573003/diff/1/ui/compositor/layer.cc#newco...
> ui/compositor/layer.cc:585: : 1.f;
> Any reason we're not passing the renderer's DSF instead of recomputing it?
> 
> In the caller, frame_size_in_dip is computed explicitly from the frame_size
> (surface_size) and the renderer's DSF. It seems it would avoid additional
> precision issues for non-pow2 DSF.

Unfortunately frame_size_in_dip is rounded. I'm not sure if it makes sense to
use the rounded frame size or the unrounded size in computing the scale, but for
this I chose the rounded version.

[piman, 2014-11-12 03:00:11]

On Tue, Nov 11, 2014 at 6:49 PM, <jbauman@chromium.org> wrote:

> On 2014/11/12 02:36:58, piman (Very slow to review) wrote:
>
>> https://codereview.chromium.org/719573003/diff/1/ui/compositor/layer.cc
>> File ui/compositor/layer.cc (right):
>>
>
>
> https://codereview.chromium.org/719573003/diff/1/ui/
> compositor/layer.cc#newcode585
>
>> ui/compositor/layer.cc:585: : 1.f;
>> Any reason we're not passing the renderer's DSF instead of recomputing it?
>>
>
>  In the caller, frame_size_in_dip is computed explicitly from the
>> frame_size
>> (surface_size) and the renderer's DSF. It seems it would avoid additional
>> precision issues for non-pow2 DSF.
>>
>
> Unfortunately frame_size_in_dip is rounded. I'm not sure if it makes sense
> to
> use the rounded frame size or the unrounded size in computing the scale,
> but for
> this I chose the rounded version.
>

DelegatedRendererLayerImpl uses the DSF as coming from the renderer, not
the ratio of the rounded DIP size to the renderer "native" size.
I think we should be consistent.


>
> https://codereview.chromium.org/719573003/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jbauman, 2014-11-12 03:53:50]

PTAL, switched to directly use the scale factor from the renderer.

[piman, 2014-11-12 04:20:10]

LGTM except for one thing, thanks.

https://codereview.chromium.org/719573003/diff/20001/content/browser/composit...
File content/browser/compositor/delegated_frame_host.h (right):

https://codereview.chromium.org/719573003/diff/20001/content/browser/composit...
content/browser/compositor/delegated_frame_host.h:271: float
current_scale_factor_;
new field needs initializer

[jamesr, 2014-11-12 17:32:27]

lgtm

[jbauman, 2014-11-13 00:00:08]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2014-11-13 00:01:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/719573003/40001

[commit-bot: I haz the power, 2014-11-13 01:10:41]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2014-11-13 01:11:25]

Patchset 3 (id:??) landed as
https://crrev.com/b71b07c2279f6c8b33aa65e8bf31aedcef35d750
Cr-Commit-Position: refs/heads/master@{#303950}