Chromium的绘制

Chromium的绘制也要从WM_PAINT的开始

HWNDMessageHandler是Chromium中UI和系统消息的媒介。它来全权处理了。

好了，一个WM_PAINT消息来了。

void HWNDMessageHandler::OnPaint(HDC dc) 中，关键代码如下：

1scoped_ptr<gfx::CanvasPaint> canvas(

2          gfx::CanvasPaint::CreateCanvasPaint(hwnd()));

3      delegate_->HandlePaint(canvas->AsCanvas());

此处的 gfx::CanvasPaint就是一个平台无关的画布，new一个出来，scoped住，离开这里时就会执行它的析构。

class CanvasPaintWin : public gfx::CanvasPaint, public gfx::CanvasSkiaPaint 这里的CanvasPaint其实是CanvasPaintWin 的化身。

CanvasSkiaPaint 的析构会执行

01virtual ~CanvasSkiaPaint() {

02    if (!isEmpty()) {

03      skia::PlatformCanvas* canvas = platform_canvas();

04      canvas->restoreToCount(1);

05      // Commit the drawing to the screen

06      skia::DrawToNativeContext(canvas, paint_dc_, ps_.rcPaint.left,

07                                ps_.rcPaint.top, NULL);

08    }

09    if (for_paint_)

10      EndPaint(hwnd_, &ps_);

11  }

最终走到平台相关的绘制了，当前是GDI的BitBlt，GdiAlphaBlend等 

看不到主动调用某些函数，而是放到某些对象中去执行，在chromium中非常常见。

好了，绘制的画布搞清楚了，那绘制过程是如何的呢。往回看这句

1delegate_->HandlePaint(canvas->AsCanvas())

这里的delegate_声名是 HWNDMessageHandlerDelegate* delegate_;

class VIEWS_EXPORT NativeWidgetWin : public internal::NativeWidgetPrivate,
                                     public HWNDMessageHandlerDelegate
大部分情况下是NativeWidgetWin 的化身了。

继而会走到如下里面

1void NativeWidgetWin::HandlePaint(gfx::Canvas* canvas) {

2  delegate_->OnNativeWidgetPaint(canvas);

3}

这里的 delegate_声名是 internal::NativeWidgetDelegate* delegate_; 

1class VIEWS_EXPORT Widget : public internal::NativeWidgetDelegate,

2                            public FocusTraversable

如上，会进入到 Widget 的 OnNativeWidgetPaint中

1void Widget::OnNativeWidgetPaint(gfx::Canvas* canvas) {

2  // On Linux Aura, we can get here during Init() because of the

3  // SetInitialBounds call.

4  if (native_widget_initialized_)

5  GetRootView()->Paint(canvas);

6}

终于找到了老窝，这里得到root_view就开始遍历Paint了。他们的Paint结果最后通过 canvas绘制到了屏幕上了！