我们假设网页中包含了一个canvas元素，并且这个canvas元素是通过WebGL接口来渲染的。在Chromium中，一个网页被组织为一棵Layer树，其中网页包含的canvas元素就作为一个单独的Layer存在。这个Layer通过WebGL接口渲染在一个OpenGL纹理中（Texture），这个Texture最终通过一种称为Mailbox的机制从Render端传递给Browser端合成。

        当网页内容发生变化时，Render端使用一种称为委托渲染器（Delegated Renderer）的机制来渲染网页的UI。Delegated Renderer并没有直接在Render端中渲染网页UI，它仅仅是收集和整理渲染网页UI所需要的信息和资源。Delegated Renderer最后会将收集和整理好的信息和资源封装在一个Compositor Frame中。一个Compositor Frame描述的就是一个网页渲染帧。注意，如果网页包含了使用WebGL接口渲染的canvas元素，那么上述Compositor Frame还会包含有这些canvas元素所对应的Texture的信息。

        Delegated Renderer收集和整理渲染网页UI所需要的信息和资源完毕，就会向Browser端发送一个类型为ViewHostMsg_SwapCompositorFrame的IPC消息，以便可以将得到的Compositor Frame发送给Browser端进行合成。

        在Android 5.0之前，Render端是将网页UI渲染在一个Texture中的，然后再通过Mailbox机制将该Texture从Render端传递给Browser端进行合成。但是从Android 5.0开始，Render端就不再采用这种方式，而是采用上述的Delegated Renderer方式。从上面的分析可以知道，Delegated Renderer直接将渲染网页UI所需要的信息和资源传递给Browser端进行合成，这样可以减少一个中间环节，就是将网页UI渲染在一个Texture中的环节，因而就可以提高渲染效率。

        在上述的网页合成过程中，Render端将一个Compositor Frame发送给Browser端之后，不会等待Browser端处理完成这个Compositor Frame之后再去处理下一个Compositor Frame，因为这样效率就太低了，而是同时处理下一个Compositor Frame，但是这样做会有一个资源同步问题。Render端发送给Browser端的Compositor Frame所引用的资源是在Render端的OpenGL上下文中创建的，但是这些资源同时又会被Browser端使用，即同时会在Browser端的OpenGL上下文中使用。这样就必须要保证Render端的OpenGL上下文和Browser端的OpenGL上下文不会同时使用同一个资源。

       为了解决Render端和Browser端的OpenGL上下文之间的资源同步问题，Render端在处理下一个Compositor Frame的时候，不能使用上一个Compositor Frame所引用的资源。Browser端执行完成合成操作之后，会将之前Render端发送过来的Compositor Frame所引用的资源返回给Render端。这时候Render端就可以继续使用返回来的资源了。这就是Render端和Browser端的OpenGL上下文之间的资源同步方式。

       WebGL端和Browser端的OpenGL上下文之间的资源同步方式有所不同。WebGL端和Browser端的OpenGL上下文需要同步的资源就是它们之间通过Mailbox机制传递的Texture。为了提到渲染效率，Render端在WebGL端还没有渲染完成通过Mailbox传递的Texture之前，就已经将它封装在Compositor Frame中传递给Browser端了。为了保证这个Texture在Browser端执行合成操作的时候已经渲染完毕，WebGL端会在自己的OpenGL上下文中插入一个同步点（Sync Point）。这个插入的Sync Point同样会通过Mailbox机制传递给Browser端。Browser端在使用这些通过Mailbox机制传递过来的Texture之前，需要检查同时关联的Sync Point是否已经被调度过了。如果已经被调度过，那么就说明它所描述的Texture已经渲染完毕，这时候Browser端就可以使用它们了。这实际上是一个生产者-消费者问题。

       前面提到，WebGL端、Render端和Browser端本身并不负责执行GPU命令，它们负责生成GPU命令，然后传递给GPU线程执行。WebGL端、Render端和Browser端生成的GPU命令是通过共享内存传递给GPU线程的，如图4所示：

图4 WebGL/Render/Browser和GPU线程之间的GPU命令传递方式

       Render端、WebGL端和Browser端在与GPU线程建立了一个GPU通道之后，会将该GPU通道封装在一个WebGraphicsContext3DCommandBufferImpl对象中。这个WebGraphicsContext3DCommandBufferImpl对象内部包含了一个CommandBufferProxyImpl对象。每一个CommandBufferProxyImpl对象在GPU线程中又会有一个对应的GpuCommandBufferStub对象。以后Render端、WebGL端和Browser端与GPU线程就是通过上述的CommandBufferProxyImpl对象和GpuCommandBufferStub对象来传递和执行GPU命令的。

       其中，CommandBufferProxyImpl对象负责生成GPU命令，并且将生成的GPU命令保存在一块共享内存中。在合适的时候，CommandBufferProxyImpl对象会通知GpuCommandBufferStub对象到上述的共享内存中将还没有执行的GPU命令提取出来执行。

       我们知道，有些GPU命令除了命令本身，还附带有数据，例如glBufferData命令。这些数据也是通过共享内存传递给GPU线程的。GPU命令附带的数据有可能非常大，并且大到超过系统允许创建的最大共享内存块。Chromium使用一种称为Bucket的机制来解决该问题。每一个Bucket都关联有一个ID，并且每一个Bucket一次只可以传递固定大小的的数据给GPU线程。当一个Bucket不能一次性传递完一个GPU命令附带的数据时，那么该Bucket就会分多次进行数据传递。当GPU命令附带的数据传递完毕，再传递GPU命令本身，不过这时候GPU命令关联有一个Bucket ID，表示它所附带的数据可以通过该关联的Bucket ID找到。

       以上就是Chromium硬件加速渲染机制涉及到的基础知识，只有彻底理解这些基础知识，后面我们才可以更好地研究Chromium是如何硬件加速渲染网页UI的。为了彻底理解这些基础知识，接下来我们还会结合源码来进一步分析本文所涉及到的知识点，包括：

       1. OpenGL上下文绘图表面初始化过程分析。

       2. OpenGL上下文创建过程分析。

       3. OpenGL命令执行过程分析。

       4. OpenGL上下文调度过程分析。

       5. OpenGL上下文资源同步过程分析。