Chromium的绘制

Chromium的绘制也要从WM_PAINT的开始

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

好了，一个WM_PAINT消息来了。

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

1	scoped_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 的析构会执行

01	virtual ~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中非常常见。

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

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

这里的delegate_声名是 HWNDMessageHandlerDelegate* delegate_;

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

继而会走到如下里面

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

2	delegate_->OnNativeWidgetPaint(canvas);

3

}

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

1	class VIEWS_EXPORT Widget : public internal::NativeWidgetDelegate,

2	public FocusTraversable

如上，会进入到  Widget 的   OnNativeWidgetPaint中

1	void 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绘制到了屏幕上了！