Yesterday I described hypothetical "tree-SIMT" coprocessor to implement webpage layout within. Today I'll discuss compositing webpages!
So what would I need from this hardware?
* Textual "glyphs"
* Images
* Solid fills
* Gradients
* Trapazoids (for borders)
* Pixel blending
Occasionally:
* Matrix transforms
* Gaussian blurs (for shadows)
Shouldn't require a full GPU for you, could be done using a "display list". Which were in use within some early-ish home computers.
1/4?
I'd feed this webpage compositor a sorted (by topleft corner y then x) array of "sprites". When I hit the x,y coordinate of the next sprite I'd start running its program until I hit its width. Alongside as many background sprites as I can before I need to output the pixel, at which I'd save aside the need to pre-blend these sprites.
To handle height maintain a "scanline" of sprites. To be merge-sorted into the displaylist to produce the next scanline, until we hit the sprite's height.
2/3?
@alcinnz I think this is standard scanline rendering. VPRI's approach was I think to convert everything into trapezoids, including text glyphs. Libart does something similar. I'm not sure what Skia does but it's probably worth looking at.
Rectangles are just a special case of trapezoids, and solid fill is just a special case of gradients. For curved shapes you can probably get a better approximation with fewer objects by using quadratic splines, which increases the cost of finding the edge from one add per scanline to two, which can be done in parallel.
You want to do your matrix transforms before you start iterating over scanlines.
Convolution filtering is a broad space, and Gaussian blurs are a particularly efficient point in that space. They aren't a particularly accurate representation of real-world shadows; fuzzy shadows from the sunlight come from convolving the silhouette with the image of the sun, the which is usually a filled circle of constant brightness.
@radehi Absolutely! Sorry if these points didn't across well in my thread.