ash: HiDPI user avatar for SessionController

ui/gfx/image/mojo/image_skia.mojom

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module gfx.mojom;
+
+// Mojo transport for ImageSkiaRep via shared buffer.
+struct ImageSkiaRep {
+  // Shared buffer handle to holds a serialized SkBitmap.
+  handle<shared_buffer> shared_buffer_handle;
+
+  // Byte size of the shared buffer.
+  uint32 buffer_byte_size;

[Tom Sepez, 2017/03/23 18:11:39]

Could it be bigger than this on 64bit platforms?
Do we validate this against info from the actual handle itself?

[xiyuan, 2017/03/23 18:30:41]

Maybe in the future. For now, I don't think we use such huge images. uint32 is
4G, rought 1G ARGB pixels. And if image is this big, we should probably not use
this transport. How about add a CHECK in traits to ensure we don't overflow?
If the info is incorrect, I imagine the Map call would fail and current code
bail on that. Is this good enough?

If not, is there a way to get the size info from the handle? I did not find out
how to do that.

[xiyuan, 2017/03/23 19:45:23]

Changed uint32 -> uint64 and added a DCHECK for huge images (> 4k x 4k).

+
+  // Corresponding scale of the bitmap.
+  float scale;

[Tom Sepez, 2017/03/23 18:11:39]

Can this be zero or negative?

[xiyuan, 2017/03/23 18:30:41]

It should never be <= 0. I could add DCHECK in traits. Is there other way you
want to add to enforce this?

[xiyuan, 2017/03/23 19:45:23]

Actually, the scale can be 0 for an unscaled ImageSkiaRep. Fixed that and added
a test case. Also added a DCHECK to catch scale < 0 case.

+};
+
+// Mojo transport for existing representations of an ImageSkia via shared
+// buffer. Note it is caller's responsibility to ensure the ImageSkia contains
+// all needed representations.
+struct ImageSkia {
+  array<ImageSkiaRep> image_reps;
+};