Use RgbaColor in DesktopFrameGenerator and add RgbaColorTest

webrtc/modules/desktop_capture/rgba_color.cc

 /*
  *  Copyright (c) 2016 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
 #include "webrtc/modules/desktop_capture/rgba_color.h"
 
+#include "webrtc/typedefs.h"
+
 namespace webrtc {
 
 namespace {
 
 bool AlphaEquals(uint8_t i, uint8_t j) {
   // On Linux and Windows 8 or early version, '0' was returned for alpha channel
   // from capturer APIs, on Windows 10, '255' was returned. So a workaround is
   // to treat 0 as 255.
   return i == j || ((i == 0 || i == 255) && (j == 0 || j == 255));
 }
 
 }  // namespace
 
 RgbaColor::RgbaColor(uint8_t blue, uint8_t green, uint8_t red, uint8_t alpha) {
   this->blue = blue;
   this->green = green;
   this->red = red;
   this->alpha = alpha;
 }
 
 RgbaColor::RgbaColor(uint8_t blue, uint8_t green, uint8_t red)
     : RgbaColor(blue, green, red, 0xff) {}
 
 RgbaColor::RgbaColor(const uint8_t* bgra)
     : RgbaColor(bgra[0], bgra[1], bgra[2], bgra[3]) {}
 
+// Converting from or to uint32 in big-endian system has not been supported.
+#if defined(WEBRTC_ARCH_LITTLE_ENDIAN)
+RgbaColor::RgbaColor(uint32_t bgra)
+    : RgbaColor((bgra & 0xff000000) >> 24,

[Sergey Ulanov, 2016/09/20 21:06:41]

nit: the old version of this constructor with reinterpret_cast<> is perfectly
acceptable (assuming little-endianness), I don't think you had to change it. The
problem with reinterpret_cast<> in ToUInt32() was that we shouldn't make
assumption about struct layout in memory. It is not a problem here: uint32_t is
guaranteed to be represented as 4 continuous bytes.

[Hzj_jie, 2016/09/20 23:50:12]

Then I think we do not need to add big-endian or little-endian specific
treatment for this constructor. The input uint32_t should always in 'bgra' order
from left to right, no matter big-endian or little-endian. The consumer should
handle it correctly. What do you think?

+                (bgra & 0x00ff0000) >> 16,
+                (bgra & 0x0000ff00) >> 8,
+                (bgra & 0x000000ff)) {}
+#endif
+
 bool RgbaColor::operator==(const RgbaColor& right) const {
   return blue == right.blue && green == right.green && red == right.red &&
          AlphaEquals(alpha, right.alpha);
 }
 
 bool RgbaColor::operator!=(const RgbaColor& right) const {
   return !(*this == right);
 }
 
+// Converting from or to uint32 in big-endian system has not been supported.
+#if defined(WEBRTC_ARCH_LITTLE_ENDIAN)

[Sergey Ulanov, 2016/09/20 21:06:41]

It's better to put this inside the body of this function and then add  add
#error for big-endian case:
#else
 #error Big-endian is not implemented.

Same for the function above.

[Hzj_jie, 2016/09/20 23:50:12]

Since supporting big-endian is pretty simple, instead of adding an compiling
error, I would prefer to implement it.

+uint32_t RgbaColor::ToUInt32() const {
+  return (blue << 24) | (green << 16) | (red << 8) | alpha;
+}
+#endif
+
 }  // namespace webrtc