C++

1. Assimp 目前为止，我们已经可以绘制一个物体，并添加不同的光照效果了。但是我们的顶点数据太过简单，只能绘制简单的立方体。但是房子汽车这种不规则的形状我们的顶点数据就很难定制了。索性，这部分并

1. 投光物 继续上一节的流程，到目前为止，我们介绍的都是点光源。但是现实世界中，光源的类型却要相对复杂一些。大概会有这么几种形式：定向光、点光源、聚光等等。 2. 定向光 当一个光源处于很远的地方时

1. 光照 显示世界中，光照环境往往是相对复杂的。因为假设太阳作为世界的唯一光源，那么太阳光照在物体A上A将阳光进行反射后，A又做为一个新的光源共同作用于另一个物体B。所以于B来讲光源是复杂的。然而这

1. 摄像机 摄像机就好像是我们的眼睛，我们从摄像机的方向观察世界空间中的模型。摄像机远离模型，模型自然就变小了（透视投影下），然而，在GL中事实上并没有摄像机的概念。但是我们可以通过移动世界空间远离

GL中的坐标系是标准设备坐标，即他的每个坐标轴的取值范围都是[-1.0,1.0]。通常，我们输入到顶点着色器中的顶点坐标都会被转换为标准化设备坐标，然后进行光栅化，转变成屏幕坐标。然而事实上，从顶点坐

1. 纹理 在OpenGL中，纹理是一种常用的技术，用于将图像或图案映射到3D模型的表面上，以增加图形的细节和真实感 2. 纹理坐标 纹理坐标在x和y轴上，范围为0到1之间（注意我们使用的是2D纹理图

1. GLSL语言 glsl语言是用来编写着色器的，通过一段一段包含main函数的程序片段，告诉渲染引擎怎么去渲染内容。 glsl语言的语法有点类似c语言风格，只是增加了一些特有的关键字来修饰变量，下

gclient 是由 Google 用 Python 开发的一套跨平台的git仓库管理工具,它的作用类似 git 的 submodule，用来将多个git仓库组成一个solution进行管理，比如ch

1. VIZ的三个端 在设计层面上 viz 的架构如下图所示： 在设计上 viz 分了三个端，分别是 client 端, host 端和 service 端。 client 端用于生成要显示的画面(C

在 Chromium 中 viz 的核心逻辑运行在 GPU 进程中，负责接收其他进程产生的 viz::CompositorFrame（简称 CF），然后把这些 CF 进行合成，并将合成的结果最终渲染在

blink 中实现了2种 canvas，分别是 blink::HTMLCanvasElement 和 blink::OffscreenCanvas ，前者对应 html/dom 中的 canvas，后

1. Chromium 的渲染流水线 Blink —> Paint -> Commit -> (Tiling ->) Raster -> Activate -> Draw(Submit) —> Viz

1. Trace chromium 在 base 库中提供了 base::trace_event::TraceLog 类，该类是 TRACE_EVENT* ， TRACE_COUNTER* 等宏的底层

Command Buffer 是支撑 Chromium 多进程硬件加速渲染的核心技术之一。它基于 OpenGLES2.0 定义了一套序列化协议，这套协议规定了所有 OpenGLES2.0 命令的序列化

资源共享指的是在一个 Context 中的创建的 Texture 资源可以被其他 Context 所使用。一般来讲只有相同 share group Context 创建的 Texture 才可以被共享

Chromium 中的多线程机制由 base 库提供，要理解 Chromium 中的多线程机制，首先要理解的概念就是 base::MessageLoop 和 base::TaskScheduler ，

默认新标签页修改方法： 1. 找到chrome/browser/ui/browser_tabstrip.cc文件 找到变量NavigateParams params： 修改为： 2. 找到chrome

1. 为什么需要同步 由于 OpenGL API的执行是异步的，所以需要同步，如果是这些API是同步的就没有这个话题了。异步API可以进行缓存，从而可以在合适的时机批量的将这些API调用（称为API命

基于chromium103版本 1. 自定义扩展API接口 chromium默认扩展api接口中有chrome.runtime.*,和chrome.send.*等，现在我们就仿照chrome.runt

Mojo 是一个跨平台 IPC 框架，它诞生于 chromium ，用来实现 chromium 进程内/进程间的通信。目前，它也被用于 ChromeOS。 在我们代码应用中，如何使用Mojo来作进程间