This might be a scope creep at the very beginning of the project, but the original premise of "rendering images without <img>" is quite simple and would boil down to finding a way to express pixels through dom elements, and doing image manipulation to compress an original image's pixels into a smaller element.
Problem is, the DOM wasn't made for rendering a million elements at a time, and since we're stuck with CPU drawing and processing (as it turns out, sending data from the GPU and extracting it every drawing frame is worse than using the CPU for a small enough number of elements - which is the only thing that we can do anyways without crashing the browser), we can't do nothing but render small, static images.
So, since we are graphics programming nuts, we're going to transform HTML into a graphics rendering engine. The solution to this is the <svg> tag! We are restricted to not using the style, fill and stroke tags, which makes actually visualizing the paths we draw a tad bit harder, but it's still possible.
If we're going to just draw a wireframe, we don't have to worry about implementing depth testing, which saves quite a lot of time. This will follow 3 main steps, one usual to graphics programming will know (but, however, in a far more botched manner):
- Processing and transforming vertices
- Connecting vertices (primitive assembler)
- Drawing vertices (rasterizer)
We can skip some steps like the fragment shader (we don't have fragments, only edges because of ), proper rasterizing (we don't have pixels) and coordinate transform from normalized screen coordinates to view coordinates because, again, we don't have pixels. This will mostly be handled by the ViewBox attribute in svg.
This might be a scope creep at the very beginning of the project, but the original premise of "rendering images without
<img>" is quite simple and would boil down to finding a way to express pixels through dom elements, and doing image manipulation to compress an original image's pixels into a smaller element.Problem is, the DOM wasn't made for rendering a million elements at a time, and since we're stuck with CPU drawing and processing (as it turns out, sending data from the GPU and extracting it every drawing frame is worse than using the CPU for a small enough number of elements - which is the only thing that we can do anyways without crashing the browser), we can't do nothing but render small, static images.
So, since we are graphics programming nuts, we're going to transform HTML into a graphics rendering engine. The solution to this is the
<svg>tag! We are restricted to not using thestyle,fillandstroketags, which makes actually visualizing the paths we draw a tad bit harder, but it's still possible.If we're going to just draw a wireframe, we don't have to worry about implementing depth testing, which saves quite a lot of time. This will follow 3 main steps, one usual to graphics programming will know (but, however, in a far more botched manner):
We can skip some steps like the fragment shader (we don't have fragments, only edges because of ), proper rasterizing (we don't have pixels) and coordinate transform from normalized screen coordinates to view coordinates because, again, we don't have pixels. This will mostly be handled by the ViewBox attribute in svg.