
在使用p5.js配合webgl渲染器进行图形开发时,开发者可能会注意到一个有趣的性能现象:当首次调用image()函数绘制图像时,其所需时间远超后续对同一图像的绘制操作。这在需要频繁绘制大量图像,例如构建瓦片地图或复杂背景的场景中尤为明显。
以下面的代码为例,它尝试了两种绘制方式:一种是逐个瓦片绘制,另一种是将所有瓦片预先绘制到一个createGraphics对象中,然后作为一个整体图像绘制。
let img;
let NROWS = 55;
let NCOLS = 29;
const TILE_WIDTH_HALF = 32;
const TILE_HEIGHT_HALF = 16;
const HALF_WIDTH = 950;
const HALF_HEIGHT = 450;
let start, end;
let bg; // 用于预渲染背景的p5.Graphics对象
function preload() {
img = loadImage("tile.png"); // 预加载瓦片图像
}
// 预填充背景图形:将所有瓦片绘制到bg图形对象中
function populateBackground() {
bg = createGraphics(HALF_WIDTH*2, HALF_HEIGHT*2);
for (let row=0; row<NROWS; row++) {
for (let col=0; col<NCOLS; col++) {
x = col*TILE_WIDTH_HALF*2 + (TILE_WIDTH_HALF * (row%2)+1)
y = row*TILE_HEIGHT_HALF;
bg.image(img, x, y); // 绘制到离屏图形
}
}
}
// 逐个瓦片绘制到主画布
function drawTileByTile() {
background(100);
start = millis();
for (let row=0; row<NROWS; row++) {
for (let col=0; col<NCOLS; col++) {
x = col*TILE_WIDTH_HALF*2 + (TILE_WIDTH_HALF * (row%2)+1) - HALF_WIDTH;
y = row*TILE_HEIGHT_HALF - HALF_HEIGHT;
image(img, x, y); // 绘制到主画布
}
}
end = millis();
return (end-start);
}
// 将预填充的图形作为单个图像绘制
function drawAsImage() {
background(100);
start = millis();
image(bg,-HALF_WIDTH,-HALF_HEIGHT); // 绘制预渲染的bg图像
end = millis();
return (end-start);
}
function setup()
{
createCanvas(HALF_WIDTH*2, HALF_HEIGHT*2, WEBGL); // 使用WEBGL渲染器
populateBackground(); // 在setup中预填充背景
// 测量逐瓦片绘制的性能
let elapsed_ms = [];
for (let n=0; n<10; n++) {
elapsed_ms.push(drawTileByTile().toFixed(3));
}
console.log("逐瓦片绘制时间 (ms):", elapsed_ms);
// 测量整体图像绘制的性能
elapsed_ms = [];
for (let n=0; n<10; n++) {
elapsed_ms.push(drawAsImage().toFixed(3));
}
console.log("整体图像绘制时间 (ms):", elapsed_ms);
noLoop();
}
function draw()
{
// draw函数为空,因为我们只在setup中测量一次性性能
}运行上述代码,我们观察到的控制台输出(可能因机器而异,但趋势一致):
逐瓦片绘制时间 (ms): ['114.400', '35.400', '37.000', '31.800', '54.200', '51.900', '33.000', '34.400', '30.200', '31.200'] 整体图像绘制时间 (ms): ['1.000', '0.100', '0.100', '0.000', '0.100', '0.000', '0.000', '0.000', '0.000', '0.000']
从结果中可以清晰地看到,无论是drawTileByTile()还是drawAsImage(),第一次调用所需的时间都显著高于后续调用。特别是drawAsImage(),首次调用需要1ms,而后续几乎都在0.1ms甚至0ms。drawTileByTile()的首次调用更是高达114.4ms,而后续稳定在30-50ms。
这种首次调用性能显著下降的现象,其根源在于p5.js在WEBGL渲染模式下处理图像的方式,特别是涉及到WebGL纹理的创建和数据上传。
图像作为WebGL纹理: 当你在p5.js的WEBGL模式下使用image()函数绘制p5.Image或p5.Graphics对象时,这些图像数据并不会直接在屏幕上绘制。相反,它们会被用作一个WebGL纹理(Texture)。这个纹理随后会被绑定到一个GLSL着色器程序,该程序负责将纹理像素映射到由image()函数指定坐标所定义的三角形上。
图形内存分配与数据上传: 要将一个p5.Image实例用作WebGL纹理,首先需要向图形处理单元(GPU)的显存申请分配一块内存。随后,原始的图像数据(通常是CPU内存中的像素数组)必须被复制到这块已分配的GPU显存中。这个过程,即从CPU内存到GPU显存的数据传输,是一个相对耗时的操作。
纹理缓存机制: p5.js为了优化性能,实现了纹理缓存机制:
因此,首次调用image()时,GPU显存的分配和图像数据的首次上传是不可避免的一次性开销。一旦这些操作完成,后续的调用就可以直接利用已存在于GPU显存中的纹理,只需执行绘制三角形和绑定纹理等相对轻量的操作,因此速度会快得多。
理解了首次调用慢的原因后,我们可以采取相应的策略来优化性能:
预加载与预处理:
最小化图像数据修改:
理解WEBGL模式的开销:
p5.js在WEBGL模式下首次调用image()函数时出现的性能延迟,是WebGL纹理机制中图形内存分配和数据从CPU到GPU传输的固有开销所致。这种开销是一次性的,后续调用由于纹理缓存机制的存在而变得非常迅速。
为了优化此类性能瓶颈,核心策略是提前完成一次性开销:在程序初始化阶段(如preload()或setup()中)预加载、预渲染和预热所有重要的图像和图形对象。通过将多个小图像组合成一个大的p5.Graphics对象,并利用p5.js的纹理缓存机制,可以显著提升应用程序的渲染效率和用户体验。在设计p5.js WEBGL项目时,理解并利用这些机制是构建高性能图形应用的关键。
以上就是p5.js WebGL渲染性能探究:首次调用为何显著缓慢?的详细内容,更多请关注php中文网其它相关文章!
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号