Exploring the Limitations of Using Console.log as a Pixel Renderer

I've been diving into an interesting experiment where I render SDF ray-marching graphics using styled `console.log` calls. Each 'pixel' in this scenario is essentially a space character that gets a background color applied via `%c` in the log arguments. I'm not using any traditional techniques like canvas or WebGL. My scene has soft shadows, ambient occlusion, and two orbiting point lights, typically at around 42 by 26 pixels, raking through about 11,000 ray marching steps on each frame.

I've encountered several challenges with this approach, and I'm curious how others might tackle them:

1. Each frame requires one `console.log` call with over 1000 `%c` arguments, creating a formatted string that can be between 80 to 120kb. Are there any hidden tricks at the Chrome DevTools level that could help overcome this limitation?
2. Is it possible to implement partial redraws since the console seems to only support appending new logs? Has anyone figured out a diffing strategy that can meaningfully reduce redundant logs?
3. Given that soft shadows require a secondary ray-march for every light per pixel, is there a way to use a SharedArrayBuffer along with a worker pool to pre-compute the framebuffer before logging, or would the transfer costs negate any benefits?
4. Would utilizing a WASM SDF evaluator improve performance, or is the rendering delay in DevTools the actual bottleneck here?
5. Lastly, is there a practical way to employ temporal supersampling—alternating sub-pixel offsets in consecutive frames—considering the latency issues in console reflows?
6. To top it off, I'm dealing with memory creep due to uncleared frames. Any advice on handling that beyond just clearing every few frames?