17370845950

WebGL是直接调用GPU的底层接口，需手动管理着色器、缓冲区、矩阵变换和帧循环；动画逻辑应置于顶点着色器中通过uniform传时间实现GPU并行计算，避免CPU逐顶点运算；动态纹理更新须用texImage2D并确保绑定与格式一致；混合2D时需正确配置alpha及合成方式。

WebGL 不是用来“增强” HTML5 动画的装饰工具，它是绕过 canvas 2D 渲染管线、直接调用 GPU 的底层接口。想靠它提升动画性能，得先接受：你不再写 requestAnimationFrame + ctx.fillRect，而是写着色器、管理缓冲区、处理矩阵变换。

WebGL 动画必须手动控制帧循环，不能依赖 CSS 或 canvas 2D 自动机制

HTML5 动画常依赖 CSS animation 或 canvas 2D 的简单绘图循环，但 WebGL 没有内置“动画系统”。所有帧更新都由你通过 requestAnimationFrame 驱动，且每一帧必须显式重绘：

• gl.clear() 必须每帧调用，否则上一帧残留像素会叠加
• gl.drawArrays() 或 gl.drawElements() 必须在每次循环中执行，不调用就不会出图像
• 状态（如绑定的纹理、着色器程序）不会自动重置，需手动管理或复位

顶点着色器里做动画比 JS 算位置更高效，但必须用 uniform 或 attribute 传时间

把动画逻辑写在 JavaScript 里再传顶点坐标，是常见误区——这等于 CPU 计算每个顶点，再上传 GPU，毫无性能优势。真正高效的路径是把时间变量传进着色器，在 GPU 上并行计算：

attribute vec2 a_position;
uniform float u_time;
void main() {
  vec2 offset = vec2(sin(u_time * 0.5), cos(u_time)) * 0.2;
  gl_Position = vec4(a_position + offset, 0.0, 1.0);
}

• u_time 是 JS 每帧用 gl.uniform1f(timeLoc, performance.now() / 1000) 更新的 uniform
• 避免在顶点着色器里调用复杂函数（如 pow 多次嵌套），移动端驱动可能编译失败
• 若需逐顶点不同节奏，改用 attribute float a_phase + uniform 时间，而非 JS 算好再上传数组

用 texImage2D 动态更新纹理实现逐帧动画时，注意格式与绑定顺序

想用 WebGL 播放序列帧（比如 sprite sheet 切割或视频帧），不能像 那样换 src，必须用 texImage2D 把新像素数据推到 GPU 纹理对象上：

• 每次更新前必须确保目标纹理已绑定：gl.bindTexture(gl.TEXTURE_2D, texture)
• 传入的像素数据类型（gl.UNSIGNED_BYTE）、格式（gl.RGBA）、尺寸（宽高需是 2 的幂，或开启 gl.TEXTURE_WRAP 限制）必须和首次创建时一致
• 若从 或 读帧，要等其 readyState === 4（视频）或 drawImage 完成后再调用 texImage2D，否则传空数据

混合 2D 和 WebGL 时，canvas 的 alpha: false 可能导致透明合成失效

很多项目想在 WebGL 画布上叠加 HTML 文字或 2D 图形，结果发现文字发虚、半透明层错乱——根源常是 canvas 创建时没配对 alpha 行为：

• 若 WebGL 需透明背景（如覆盖在网页其他元素上），初始化时必须设 { alpha: true }，且每帧 gl.clearColor(0,0,0,0)
• 但此时若用 ctx.drawImage(canvas, ...) 把 WebGL 画布当图片源，Chrome 默认按 premultiplied alpha 解析，而 Firefox 可能不，造成跨浏览器差异
• 稳妥做法：用 gl.readPixels() + ImageData 手动合成，或用 OffscreenCanvas（仅现代浏览器支持）隔离渲染流程

真正卡住人的从来不是怎么画一个旋转三角形，而是纹理单位没激活、帧缓冲没检查 gl.checkFramebufferStatus、或者 uniform location 返回 -1 却没查错。WebGL 的“增强”，只对愿意直面这些细节的人生效。