Tag TransportDIBs with the device scale factor they expect.

Tag TransportDIBs with the device scale factor they expect.

After DPI changes, the renderer can send paints at the old DPIness
for a few frames, until the "new DPIness" IPC arrives. Tag TransportDIBs
with the intended scale factor, so that the browser process can compensate
for paints at the wrong resolution temporarily.

Implement this compensation logic on mac.

Most of the DPI switching infrastructure still isn't hooked up, so
almost no observable behavior change.

BUG=128267
TEST=none (chrome/mac no longer crashes on DPIness change if a paint
is pending)

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

[Nico, 2012-06-13 20:01:11]

+Avi for owners

(I checked the approach in person with oshima for the software path and jamesr
for the hardware path)

[jamesr, 2012-06-13 20:01:44]

content/renderer LGTM

[Avi (use Gerrit), 2012-06-13 20:34:12]

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
File content/browser/renderer_host/backing_store.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
content/browser/renderer_host/backing_store.h:51: // DIBs. |scale_factor|
contains the expected device scale factor of the
DIBs or DIPs? Here it's DIBs.

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
File content/browser/renderer_host/backing_store_manager.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
content/browser/renderer_host/backing_store_manager.h:42: //   The desired
backing store dimensions, in DIBs.
DIBs or DIPs? Here it's DIBs.

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
content/browser/renderer_host/backing_store_manager.h:46: //   The rect to be
painted into the backing stor, in DIBs.
DIBs or DIPs? Here it's DIBs.

s/stor/store/

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/common/view...
File content/common/view_messages.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/common/view...
content/common/view_messages.h:538: // All the above coordinates are in DIP.
This is the scale factor needed
DIBs or DIPs? Here it's DIPs.

[Nico, 2012-06-13 20:38:50]

Thanks, all done.

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
File content/browser/renderer_host/backing_store.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
content/browser/renderer_host/backing_store.h:51: // DIBs. |scale_factor|
contains the expected device scale factor of the
On 2012/06/13 20:34:13, Avi wrote:
> DIBs or DIPs? Here it's DIBs.

DIPs "device-independent pixels". DIBs is something else :-) Thanks, done.

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
File content/browser/renderer_host/backing_store_manager.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
content/browser/renderer_host/backing_store_manager.h:42: //   The desired
backing store dimensions, in DIBs.
On 2012/06/13 20:34:13, Avi wrote:
> DIBs or DIPs? Here it's DIBs.

Wrong again. Done.

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/browser/ren...
content/browser/renderer_host/backing_store_manager.h:46: //   The rect to be
painted into the backing stor, in DIBs.
On 2012/06/13 20:34:13, Avi wrote:
> DIBs or DIPs? Here it's DIBs.
> 
> s/stor/store/

Done.

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/common/view...
File content/common/view_messages.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/6002/content/common/view...
content/common/view_messages.h:538: // All the above coordinates are in DIP.
This is the scale factor needed
On 2012/06/13 20:34:13, Avi wrote:
> DIBs or DIPs? Here it's DIPs.

This time it's right :-)

DIP is "device-independent pixel", which is how the aura code calls cocoa's view
units. DIB is "device-independent bitmap", which is (roughly) win32 lingo for a
bitmap.

[Avi (use Gerrit), 2012-06-13 20:44:40]

Re DIP/DIB, that's what I thought, but I wanted to make sure I wasn't
misunderstanding something.

LGTM with more nits.

https://chromiumcodereview.appspot.com/10540144/diff/4006/content/browser/ren...
File content/browser/renderer_host/backing_store.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/4006/content/browser/ren...
content/browser/renderer_host/backing_store.h:48: // Paints the bitmap from the
renderer onto the backing store.  bitmap_rect
One space after period to match rest of comment.

https://chromiumcodereview.appspot.com/10540144/diff/4006/content/browser/ren...
File content/browser/renderer_host/backing_store_manager.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/4006/content/browser/ren...
content/browser/renderer_host/backing_store_manager.h:48: //   The device scale
facctor the backing store is expected to be at.
s/facctor/factor/

[Nico, 2012-06-13 20:46:57]

both done. thanks!

https://chromiumcodereview.appspot.com/10540144/diff/4006/content/browser/ren...
File content/browser/renderer_host/backing_store.h (right):

https://chromiumcodereview.appspot.com/10540144/diff/4006/content/browser/ren...
content/browser/renderer_host/backing_store.h:48: // Paints the bitmap from the
renderer onto the backing store.  bitmap_rect
On 2012/06/13 20:44:40, Avi wrote:
> One space after period to match rest of comment.

Done.

[oshima, 2012-06-13 20:51:50]

lgtm