Part 3/3 (RWH/IOSurface) of adding with device scale factor to transport surfaces

Part 3/3 (RWH/IOSurface) of adding with device scale factor to transport surfaces

Pass the scale factor through the image transport surface to the
IOSurface creation.

Change ViewHostMsg_CompositorSurfaceBuffersSwapped to use a
params structure, because there is a limit of 5 IPC arguments.

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

[ccameron, 2013-05-22 08:39:20]

Adding piman for content and gpu changes.
Adding thakis for IOSurface changes

This is part 3 of a 3-part series which sends the correct
scale factor to CompositingIOSurfaceMac, to avoid scaled
flickering when moving across screens.

The previous parts are
https://codereview.chromium.org/15688002/ (compositor)
https://codereview.chromium.org/15685003/ (GL)
https://codereview.chromium.org/15689003/ (RWH/IOSurface) -- this change

[Nico, 2013-05-22 15:33:21]

compositing_iosurface_mac lgtm

https://codereview.chromium.org/15689003/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/compositing_iosurface_mac.mm (left):

https://codereview.chromium.org/15689003/diff/1/content/browser/renderer_host...
content/browser/renderer_host/compositing_iosurface_mac.mm:622: io_surface_size_
= pixel_io_surface_size_;
\o/

https://codereview.chromium.org/15689003/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/compositing_iosurface_mac.mm (right):

https://codereview.chromium.org/15689003/diff/1/content/browser/renderer_host...
content/browser/renderer_host/compositing_iosurface_mac.mm:366:
gfx::ScaleSize(pixel_io_surface_size_, 1.0 / scale_factor));
Does this still have to be a member variable, or can it be a local in
DrawIOSurface() now?

[ccameron, 2013-05-22 20:50:12]

Thanks!!

I've updated this to include the new parameters in the
TextureImageTransportSurface.

I also found that the scale_factor was unnecessarily being passed to the various
copy functions, so I pulled it out of there.

https://codereview.chromium.org/15689003/diff/1/content/browser/renderer_host...
File content/browser/renderer_host/compositing_iosurface_mac.mm (right):

https://codereview.chromium.org/15689003/diff/1/content/browser/renderer_host...
content/browser/renderer_host/compositing_iosurface_mac.mm:366:
gfx::ScaleSize(pixel_io_surface_size_, 1.0 / scale_factor));
On 2013/05/22 15:33:22, Nico wrote:
> Does this still have to be a member variable, or can it be a local in
> DrawIOSurface() now?

It's also used when checking HasAcceleratedSurface (and if we didn't have to
store it, we'd have to store scale factor, which we skip ATM). I renamed this to
dip_io_surace_size_ to make the units clearer.

[piman, 2013-05-22 21:55:38]

lgtm

[ccameron, 2013-05-22 22:03:36]

Thanks!!

Adding cevans for the security IPC OWNER stamp.

[Chris Evans, 2013-05-22 22:30:29]

LGTM with note.

https://codereview.chromium.org/15689003/diff/8001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/15689003/diff/8001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:1666:
gpu_params.scale_factor = params.scale_factor;
This new parameter looks to come from the untrusted renderer. Before landing,
can you make sure nothing dies horribly with weird float values (inf, nan,
negatives, tiny fractions, huge numbers).

[ccameron, 2013-05-23 00:19:59]

Thanks!!

https://codereview.chromium.org/15689003/diff/8001/content/browser/renderer_h...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/15689003/diff/8001/content/browser/renderer_h...
content/browser/renderer_host/render_widget_host_impl.cc:1666:
gpu_params.scale_factor = params.scale_factor;
On 2013/05/22 22:30:30, Chris Evans wrote:
> This new parameter looks to come from the untrusted renderer. Before landing,
> can you make sure nothing dies horribly with weird float values (inf, nan,
> negatives, tiny fractions, huge numbers).

We scale gpu_params.size by 1/scale_factor, which can result in messy values.
Those values aren't used to index into arrays, or anything that would obviously
go wrong (they're used as vertex coordinates, so strange values would be
clipped).

I tried inserting some bad values (nan, inf, 0, and -1), and the result was that
the contents area turned a solid color (which is about expected).

[commit-bot: I haz the power, 2013-05-26 20:08:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ccameron@chromium.org/15689003/8001

[commit-bot: I haz the power, 2013-05-27 05:48:34]

Change committed as 202371