Implemented browser side software compositing.

content/browser/renderer_host/software_output_device_linux.cc

Index: content/browser/renderer_host/software_output_device_linux.cc
diff --git a/content/browser/renderer_host/software_output_device_linux.cc b/content/browser/renderer_host/software_output_device_linux.cc
new file mode 100644
index 0000000000000000000000000000000000000000..3ba29ca100a01960e08bb8a9709525e1d3825fc3
--- /dev/null
+++ b/content/browser/renderer_host/software_output_device_linux.cc
@@ -0,0 +1,74 @@
+// Copyright (c) 2013 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.
+
+#include "content/browser/renderer_host/software_output_device.h"
+
+#include <X11/Xlib.h>
+#include <X11/Xutil.h>
+
+#include "third_party/skia/include/core/SkBitmap.h"
+#include "third_party/skia/include/core/SkDevice.h"
+#include "ui/compositor/compositor.h"
+
+namespace content {
+
+SoftwareOutputDevice::SoftwareOutputDevice(ui::Compositor* compositor)
+    : compositor_(compositor),
+      display_(ui::GetXDisplay()),
+      gc_(NULL),
+      image_(NULL) {
+  gc_ = XCreateGC(display_, compositor_->widget(), 0, NULL);
+}
+
+SoftwareOutputDevice::~SoftwareOutputDevice() {
+  XFreeGC(display_, gc_);

[piman, 2013/03/06 19:22:30]

When threaded compositing is on, this, and multiple calls below, is called on
the thread. The display isn't thread safe, so it's problematic to do X calls
from the other thread with the main thread display.

You really have 3 options:
- say threaded compositing doesn't work with the software device. This may be
fine for an initial approach, but you need to add checks for this, and come up
with a plan about how to enable it.
- post tasks to the main thread to do the blitting there.
- open a second display on the compositor thread, though you need to handle
synchronization between the 2 displays

I don't know whether Windows has similar restrictions or not.

+  ClearImage();
+}
+
+void SoftwareOutputDevice::ClearImage() {
+  if (image_) {
+    // XDestroyImage deletes the data referenced by the image which
+    // is actually owned by the device_. So we have to reset data here.
+    image_->data = NULL;
+    XDestroyImage(image_);
+    image_ = NULL;
+  }
+}
+
+void SoftwareOutputDevice::Resize(const gfx::Size& viewport_size) {
+  cc::SoftwareOutputDevice::Resize(viewport_size);
+
+  ClearImage();
+  if (!device_)
+    return;
+
+  const SkBitmap& bitmap = device_->accessBitmap(false);
+  image_ = XCreateImage(display_, CopyFromParent,
+                        DefaultDepth(display_, DefaultScreen(display_)),
+                        ZPixmap, 0,
+                        static_cast<char*>(bitmap.getPixels()),
+                        viewport_size_.width(), viewport_size_.height(),
+                        32, 4 * viewport_size_.width());
+}
+
+void SoftwareOutputDevice::EndPaint(cc::SoftwareFrameData* frame_data) {
+  DCHECK(device_);
+  DCHECK(frame_data == NULL);
+
+  if (!device_)
+    return;
+
+  gfx::Rect rect = damage_rect_;
+  rect.Intersect(gfx::Rect(viewport_size_));
+  if (rect.IsEmpty())
+    return;
+
+  // TODO(skaslev): Maybe switch XShmPutImage since it's async.
+  XPutImage(display_, compositor_->widget(), gc_, image_,
+            rect.x(), rect.y(),
+            rect.x(), rect.y(),
+            rect.width(), rect.height());
+}
+
+}  // namespace content