Add DPI information to video packets.

remoting/proto/video.proto

Index: remoting/proto/video.proto
diff --git a/remoting/proto/video.proto b/remoting/proto/video.proto
index 14415af4585e55ceb3f54a346d99c525de748a5d..9f8bbdb3d8ab02100ecf59abf8b9f890833def80 100644
--- a/remoting/proto/video.proto
+++ b/remoting/proto/video.proto
@@ -33,6 +33,11 @@ message VideoPacketFormat {
   // Width and height of the whole screen.
   optional int32 screen_width = 6;
   optional int32 screen_height = 7;
+
+  // Horizontal and vertical DPI of the screen. If either of these is zero or

[Wez, 2012/07/13 21:49:02]

nit: Rather than complicate calling code, mandate that they be unset or
non-zero?

[Jamie, 2012/07/13 22:17:13]

Does it complicate calling code? If the field is unset, won't the accessor
return zero? So if the caller has to cope with unset, it's actually simpler to
handle zero the same way (no need to call the has_ method).

[Wez, 2012/07/14 00:55:11]

I think that's defined by the protobuf spec, yes, in which case it makes sense
to allow zero values, yes.

+  // unset, the corresponding DPI should be assumed to be 96.

[Wez, 2012/07/13 21:49:02]

nit: It appears that Mac OS X defaults to 72dpi; my suggestion of 96 was based
on what I believe Windows assumes, so we should clarify where 96 comes from!

[Jamie, 2012/07/13 22:17:13]

Assuming most hosts are Windows, let's stick with 96 as the default, but I've
added a comment to clarify why.

+  optional int32 horizontal_dpi = 8;

[Wez, 2012/07/13 21:49:02]

nit: I think x_dpi and y_dpi would be sufficiently clear to the educated reader,
less to type, and would match the naming of the fields in SkIPoint that you've
used to carry DPI in CaptureData.

[Jamie, 2012/07/13 22:17:13]

Done.

+  optional int32 vertical_dpi = 9;
 }
 
 // TODO(hclam): Remove this message once we can obtain dirty rects from libvpx.