Render loop that uses the results of previous render tend to glitch out.
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- javascript
- Área
- computer-graphics, frontend
Línea de trabajo
Reproduce el ejemplo de index.html e index.js en Chrome, comenzando por el bucle de renderizado que llama a simulate() y getPixels(). Compara los valores sucesivos de map y la salida del canvas para determinar dónde se dejan de usar los datos de la iteración anterior o dónde se corrompen. Se considera terminado cuando las iteraciones repetidas utilizan los píxeles anteriores y producen gradualmente el aclarado esperado sin artefactos visuales.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What is wrong?
I am trying to write a continuous simulation loop on canvas, using gpu.js. The idea is to:
- Generate an initial
w * h * 4array (Uint8ClampedArrayto be more specific) - Write a gpu.js kernel, that processes that data and outputs result with
this.color - return the data with
getPixels()and override the initial data - pass the data returned in step 3 to the next simulation
- repeat steps 3-5 in a render loop
However:
- The kernel does not use the data from the previous iteration (even though when I check the
mapvariable from the browser console, it does contain results from the previous iteration). You can see that the pixels are not increasing in lightness over first couple of iterations, but are just replaced. - After a couple of render calls, the entire thing starts to glitch out entirely, drawing almost full lines of the same pixel data.
- The left-side area is not a result of failed recording - it does look like this in the browser.
- In the example code below, RGB pixels are clamped on increasing the value to avoid any overflow possibilities.
Here is the recorded result:

Where does it happen?
In the browser. (chrome 101.0.4951.67)
How do we replicate the issue?
Here is a sample I wrote:
<!-- index.html -->
...
<canvas id="daCanvas" width="512" height="512" >
...
// index.js
const canvas = document.getElementById('daCanvas');
const gl = canvas.getContext('webgl2', { premultipliedAlpha: false });
// 1.
let map = new Uint8ClampedArray(canvas.width * canvas.height * 4);
const gpu = new GPU({
canvas,
context: gl,
});
// 2.
const simulate = gpu.createKernel(function(mapData) {
if(Math.random() > 0.95) {
this.color(
Math.min(1, mapData[this.thread.x][this.thread.y][0] / 255 + 0.3),
Math.min(1, mapData[this.thread.x][this.thread.y][1] / 255 + 0.3),
Math.min(1, mapData[this.thread.x][this.thread.y][2] / 255 + 0.3),
1
);
} else {
this.color(
mapData[this.thread.x][this.thread.y][0] / 255,
mapData[this.thread.x][this.thread.y][1] / 255,
mapData[this.thread.x][this.thread.y][2] / 255,
1
);
}
})
.setOutput([canvas.width, canvas.height])
.setGraphical(true);
const render = () => {
// 3.
simulate(GPU.input(map, [canvas.width, canvas.height, 4]));
// 4.
map = simulate.getPixels();
}
// 5.
// Were using a nice slow interval for gentle simulation. Resutls for reqquestAnimationFrame loop are similar, just faster
setInterval(() => {requestAnimationFrame(render);}, 1000)
How important is this (1-5)?
It's just an experiment a'la the game of life, so let's say 2 (I take my hobby experiments seriously, but let's be honest - I am just playing with the tech).
Expected behaviour (i.e. solution)
I expected, that the image would start black, and then with each iteration, some pixels would become lighter and lighter until the image is entirely white.
Other Comments
I was trying this with several different approaches (separate kernel for processing, separate for rendering, different operations within the kernel etc), but the result was always glitchy. Even If I had just a loop that always draws whatever is in mapData and then would execute something like map[0] - 255 from the browser console, the loop would glitch out after a several loops.
- Lenguaje dominante
- JavaScript
- Estrellas
- 15.5k
- Forks
- 663
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de gpujs/gpu.js
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
-
WebGL backend silently returns all zeros for long-running kernels (no GL error, no context loss)Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 42/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
-
Bitwise result not correctAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Todos los issues de gpujs/gpu.js
Issues similares
-
factory-active factory-automatic task-bug-reproduction-success task-identify-harness-labels-done task-identify-issue-type-done
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
vercel/ai#21528 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
status: waiting triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
freeCodeCamp/freeCodeCamp#70412 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
rohitg00/ai-engineering-from-scratch#490 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 6 días