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绘制到了屏幕上了!  

你可能感兴趣的:(canvas,chrome,chromium)