Implement hidpi and pinch-zoom scaling of filter params in cc.

CC: implement HiDPI and pinch-zoom scaling of filter params.

This change implements HiDPI scaling of filter params in CC, and turns
it off in Blink. It also fixes content scaling of filter params (e.g.,
with -webkit-transform: scale(X)) as well as pinch-zoom scaling.

NOTE: this will need https://codereview.chromium.org/191053003/ to
land and roll in first.

BUG=281516, 349493

[danakj, 2014-03-07 17:35:44]

https://codereview.chromium.org/191123002/diff/1/cc/layers/render_surface_imp...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/191123002/diff/1/cc/layers/render_surface_imp...
cc/layers/render_surface_impl.cc:219:
owning_layer_->draw_properties().target_space_transform;
Invert the order here.

Transform Scale() should happen first, then PreConcat the
target_space_transform.

https://codereview.chromium.org/191123002/diff/1/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/191123002/diff/1/cc/output/gl_renderer.cc#new...
cc/output/gl_renderer.cc:552: canvas.scale(scale.Scale2d().x(),
scale.Scale2d().y());
Huh, didn't know we have Scale2d(). MathUtil::ComputeTransform2dScaleComponents
is more rigorous, but I'm not sure if it would matter here or not.

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
cc/quads/render_pass_draw_quad.h:64: gfx::Transform scale;
Since you only care about the scale components, you could pull them out in
RenderSurfaceImpl instead of storing a whole transform.

That said, this transform is the full transform from the owning layer to the
render surface. Maybe you should just apply the whole transform to the canvas?

[Stephen White, 2014-03-07 17:46:43]

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
cc/quads/render_pass_draw_quad.h:64: gfx::Transform scale;
On 2014/03/07 17:35:44, danakj wrote:
> Since you only care about the scale components, you could pull them out in
> RenderSurfaceImpl instead of storing a whole transform.

Yeah, that's probably a better idea.

> That said, this transform is the full transform from the owning layer to the
> render surface. Maybe you should just apply the whole transform to the canvas?

For one thing, the transform is a 4x4 matrix, and this is an SkMatrix, which is
3x2 (2D).

Aside from that, the bigger issue is that filters just don't handle anything
other than scales and transforms well. They're really meant to be applied as an
orthographic, device-pixels post-process. If there's a 3D transform further up
the hierarchy, that should be flattened into the RenderSurface. If there's one
directly on the layer, it should be applied after the filters. So we shouldn't
end up with any 3D transforms here, IIUC.

For my edification: what else (other than pinch zoom) can end up in this
transform? What web content /browser settings can produce it?

[danakj, 2014-03-07 17:49:23]

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
cc/quads/render_pass_draw_quad.h:64: gfx::Transform scale;
On 2014/03/07 17:46:43, Stephen White wrote:
> On 2014/03/07 17:35:44, danakj wrote:
> > Since you only care about the scale components, you could pull them out in
> > RenderSurfaceImpl instead of storing a whole transform.
> 
> Yeah, that's probably a better idea.
> 
> > That said, this transform is the full transform from the owning layer to the
> > render surface. Maybe you should just apply the whole transform to the
canvas?
> 
> For one thing, the transform is a 4x4 matrix, and this is an SkMatrix, which
is
> 3x2 (2D).
> 
> Aside from that, the bigger issue is that filters just don't handle anything
> other than scales and transforms well. They're really meant to be applied as
an
> orthographic, device-pixels post-process. If there's a 3D transform further up
> the hierarchy, that should be flattened into the RenderSurface. If there's one
> directly on the layer, it should be applied after the filters. So we shouldn't
> end up with any 3D transforms here, IIUC.
> 
> For my edification: what else (other than pinch zoom) can end up in this
> transform? What web content /browser settings can produce it?

Oh actually, because this is a transform from the owning layer to the surface
texture, it will only be scale. I was thinking the origin transform might be
built in, but that origin is in the quad rect instead. So grabbing the scale
components should be the best thing to do here. You can DCHECK that the
transform has only a 2d scale to it to encode these assumptions.

[danakj, 2014-03-07 17:50:22]

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
cc/quads/render_pass_draw_quad.h:64: gfx::Transform scale;
On 2014/03/07 17:49:23, danakj wrote:
> On 2014/03/07 17:46:43, Stephen White wrote:
> > On 2014/03/07 17:35:44, danakj wrote:
> > > Since you only care about the scale components, you could pull them out in
> > > RenderSurfaceImpl instead of storing a whole transform.
> > 
> > Yeah, that's probably a better idea.
> > 
> > > That said, this transform is the full transform from the owning layer to
the
> > > render surface. Maybe you should just apply the whole transform to the
> canvas?
> > 
> > For one thing, the transform is a 4x4 matrix, and this is an SkMatrix, which
> is
> > 3x2 (2D).
> > 
> > Aside from that, the bigger issue is that filters just don't handle anything
> > other than scales and transforms well. They're really meant to be applied as
> an
> > orthographic, device-pixels post-process. If there's a 3D transform further
up
> > the hierarchy, that should be flattened into the RenderSurface. If there's
one
> > directly on the layer, it should be applied after the filters. So we
shouldn't
> > end up with any 3D transforms here, IIUC.
> > 
> > For my edification: what else (other than pinch zoom) can end up in this
> > transform? What web content /browser settings can produce it?
> 
> Oh actually, because this is a transform from the owning layer to the surface
> texture, it will only be scale. I was thinking the origin transform might be
> built in, but that origin is in the quad rect instead. So grabbing the scale
> components should be the best thing to do here. You can DCHECK that the
> transform has only a 2d scale to it to encode these assumptions.

This is the full computation of the transform:
https://code.google.com/p/chromium/codesearch#chromium/src/cc/trees/layer_tre...

Identity * Scale.

[Stephen White, 2014-03-07 20:45:57]

Fixes done; still needs tests.

https://codereview.chromium.org/191123002/diff/1/cc/layers/render_surface_imp...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/191123002/diff/1/cc/layers/render_surface_imp...
cc/layers/render_surface_impl.cc:219:
owning_layer_->draw_properties().target_space_transform;
On 2014/03/07 17:35:44, danakj wrote:
> Invert the order here.
> 
> Transform Scale() should happen first, then PreConcat the
> target_space_transform.

Done (probably shouldn't make a difference if it really is just a scale, but
ok).

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
cc/quads/render_pass_draw_quad.h:64: gfx::Transform scale;
On 2014/03/07 17:35:44, danakj wrote:
> Since you only care about the scale components, you could pull them out in
> RenderSurfaceImpl instead of storing a whole transform.

Done.

https://codereview.chromium.org/191123002/diff/1/cc/quads/render_pass_draw_qu...
cc/quads/render_pass_draw_quad.h:64: gfx::Transform scale;
On 2014/03/07 17:49:23, danakj wrote:
> On 2014/03/07 17:46:43, Stephen White wrote:
> > On 2014/03/07 17:35:44, danakj wrote:
> > > Since you only care about the scale components, you could pull them out in
> > > RenderSurfaceImpl instead of storing a whole transform.
> > 
> > Yeah, that's probably a better idea.
> > 
> > > That said, this transform is the full transform from the owning layer to
the
> > > render surface. Maybe you should just apply the whole transform to the
> canvas?
> > 
> > For one thing, the transform is a 4x4 matrix, and this is an SkMatrix, which
> is
> > 3x2 (2D).
> > 
> > Aside from that, the bigger issue is that filters just don't handle anything
> > other than scales and transforms well. They're really meant to be applied as
> an
> > orthographic, device-pixels post-process. If there's a 3D transform further
up
> > the hierarchy, that should be flattened into the RenderSurface. If there's
one
> > directly on the layer, it should be applied after the filters. So we
shouldn't
> > end up with any 3D transforms here, IIUC.
> > 
> > For my edification: what else (other than pinch zoom) can end up in this
> > transform? What web content /browser settings can produce it?
> 
> Oh actually, because this is a transform from the owning layer to the surface
> texture, it will only be scale. I was thinking the origin transform might be
> built in, but that origin is in the quad rect instead. So grabbing the scale
> components should be the best thing to do here. You can DCHECK that the
> transform has only a 2d scale to it to encode these assumptions.

Done.

[danakj, 2014-03-07 20:54:05]

https://codereview.chromium.org/191123002/diff/20001/cc/layers/render_surface...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/191123002/diff/20001/cc/layers/render_surface...
cc/layers/render_surface_impl.cc:222: gfx::Transform scaleTransform;
owning_layer_to_target_transform

https://codereview.chromium.org/191123002/diff/20001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/191123002/diff/20001/cc/output/gl_renderer.cc...
cc/output/gl_renderer.cc:552: canvas.scale(scale.x(), scale.y());
We need to do this for software_renderer.cc too right?

https://codereview.chromium.org/191123002/diff/20001/cc/quads/render_pass_dra...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/20001/cc/quads/render_pass_dra...
cc/quads/render_pass_draw_quad.h:65: gfx::Vector2dF scale;
How about calling it |filters_scale|, move it up beside |filters| and describe
what it's for in a comment.

Use the same name for the arguments above then.

https://codereview.chromium.org/191123002/diff/20001/content/common/cc_messag...
File content/common/cc_messages.h (right):

https://codereview.chromium.org/191123002/diff/20001/content/common/cc_messag...
content/common/cc_messages.h:167: IPC_STRUCT_TRAITS_MEMBER(scale)
Cool, you'll need to update a few tests in cc_messages_unittest.cc as well.

[Stephen White, 2014-03-07 21:54:14]

https://codereview.chromium.org/191123002/diff/20001/cc/layers/render_surface...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/191123002/diff/20001/cc/layers/render_surface...
cc/layers/render_surface_impl.cc:222: gfx::Transform scaleTransform;
On 2014/03/07 20:54:05, danakj wrote:
> owning_layer_to_target_transform

I'm gonna try just pulling out the Scale2D components directly from
target_space_transform, and just doing some multiplies, instead of a big-ol'
matmult. Let me know what you think.

https://codereview.chromium.org/191123002/diff/20001/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/191123002/diff/20001/cc/output/gl_renderer.cc...
cc/output/gl_renderer.cc:552: canvas.scale(scale.x(), scale.y());
On 2014/03/07 20:54:05, danakj wrote:
> We need to do this for software_renderer.cc too right?

Done.

https://codereview.chromium.org/191123002/diff/20001/cc/quads/render_pass_dra...
File cc/quads/render_pass_draw_quad.h (right):

https://codereview.chromium.org/191123002/diff/20001/cc/quads/render_pass_dra...
cc/quads/render_pass_draw_quad.h:65: gfx::Vector2dF scale;
On 2014/03/07 20:54:05, danakj wrote:
> How about calling it |filters_scale|, move it up beside |filters| and describe
> what it's for in a comment.
> 
> Use the same name for the arguments above then.

Done.

https://codereview.chromium.org/191123002/diff/20001/content/common/cc_messag...
File content/common/cc_messages.h (right):

https://codereview.chromium.org/191123002/diff/20001/content/common/cc_messag...
content/common/cc_messages.h:167: IPC_STRUCT_TRAITS_MEMBER(scale)
On 2014/03/07 20:54:05, danakj wrote:
> Cool, you'll need to update a few tests in cc_messages_unittest.cc as well.

Done.

[danakj, 2014-03-07 22:04:16]

https://codereview.chromium.org/191123002/diff/20001/cc/layers/render_surface...
File cc/layers/render_surface_impl.cc (right):

https://codereview.chromium.org/191123002/diff/20001/cc/layers/render_surface...
cc/layers/render_surface_impl.cc:222: gfx::Transform scaleTransform;
On 2014/03/07 21:54:14, Stephen White wrote:
> On 2014/03/07 20:54:05, danakj wrote:
> > owning_layer_to_target_transform
> 
> I'm gonna try just pulling out the Scale2D components directly from
> target_space_transform, and just doing some multiplies, instead of a big-ol'
> matmult. Let me know what you think.

Yep sounds good, and we'll have to defer that to GLRenderer I think.

[danakj, 2014-03-07 22:05:02]

cools

https://codereview.chromium.org/191123002/diff/40001/cc/output/software_rende...
File cc/output/software_renderer.cc (right):

https://codereview.chromium.org/191123002/diff/40001/cc/output/software_rende...
cc/output/software_renderer.cc:523: // TODO(ajuma): In addition origin
translation, the canvas should also be
TODO can go \o/

[danakj, 2014-07-11 20:09:11]

Stephen just pointed out to me https://codereview.chromium.org/191123002/ which
I had completely forgotten about.

Does this fix your issue for you without even needing to add the transform to
the filter operation?

[danakj, 2014-07-11 20:17:40]

garykac@ if this solves your problems, senorblanco suggested you could perhaps
take over pushing this CL to the finish line.

[garykac, 2014-07-15 01:12:33]

On 2014/07/11 20:17:40, danakj wrote:
> garykac@ if this solves your problems, senorblanco suggested you could perhaps
> take over pushing this CL to the finish line.

Yep. This fixes the problem we were having.

I've got a local copy of this cl that I'll be send out once I add some tests.

[Stephen White, 2014-10-19 18:33:42]

This was cleaned up by garykac@ in https://codereview.chromium.org/394193003,
landed at r288436. Closing.