What are the real architectural limits of using…
0 reactions
What are the real architectural limits of using console.log + %c as a pixel renderer, and how would you push past them?
Context: I've been experimenting with SDF ray-marching rendered entirely via styled console.log calls — each "pixel" is a space character with a background-color CSS style injected through %c format arguments. No canvas, no WebGL. The scene includes soft shadows, AO, and two orbiting point lights at \~42×26 pixels, doing around 11k ray-march steps per frame.
I've hit a few walls I don't have good answers for and wanted to hear how people would actually approach them:
Each frame is one console.log with 1000+ %c args — the format string alone is 80–120kb. Is there a CDP-level trick that beats this, or is this just the hard ceiling?
Partial redraws seem impossible since the console only appends. Has anyone found a diffing approach that meaningfully reduces redundant output?
Soft shadows need a secondary ray-march per light per pixel — the main bottleneck. Can a SharedArrayBuffer + Worker pool realistically pre-compute the framebuffer before the log call, or does the transfer cost kill it?
Would a WASM SDF evaluator actually move the needle here, or is the bottleneck firmly on the DevTools rendering side?
Is temporal supersampling (alternating sub-pixel offsets frame-to-frame) something the human eye would even pick up given the console's reflow latency?
Memory creep from non-cleared frames — anyone have a cleaner solution than "hard clear every N frames and eat the flash"?
#technology #programming #dev #js
Context: I've been experimenting with SDF ray-marching rendered entirely via styled console.log calls — each "pixel" is a space character with a background-color CSS style injected through %c format arguments. No canvas, no WebGL. The scene includes soft shadows, AO, and two orbiting point lights at \~42×26 pixels, doing around 11k ray-march steps per frame.
I've hit a few walls I don't have good answers for and wanted to hear how people would actually approach them:
Each frame is one console.log with 1000+ %c args — the format string alone is 80–120kb. Is there a CDP-level trick that beats this, or is this just the hard ceiling?
Partial redraws seem impossible since the console only appends. Has anyone found a diffing approach that meaningfully reduces redundant output?
Soft shadows need a secondary ray-march per light per pixel — the main bottleneck. Can a SharedArrayBuffer + Worker pool realistically pre-compute the framebuffer before the log call, or does the transfer cost kill it?
Would a WASM SDF evaluator actually move the needle here, or is the bottleneck firmly on the DevTools rendering side?
Is temporal supersampling (alternating sub-pixel offsets frame-to-frame) something the human eye would even pick up given the console's reflow latency?
Memory creep from non-cleared frames — anyone have a cleaner solution than "hard clear every N frames and eat the flash"?
#technology #programming #dev #js
| 2,000 mlx | |
| 2 | |
| 0 |