Re: threaded, journaled software backend/rasterizer experiment

On Fri, Sep 23, 2011 at 4:53 PM, Taekyun Kim <[email protected]> wrote:
> For each fill operation
> 1. the source pattern is saved as a form of shader program
> 2. convert cairo path to a polygon and build edge data
> 3. add the fill command to a tile if the polygon intersects with the tile
>
> For o_surface_flush()
> 1. allocate a worker thread from thread pool for each tile

The number of worker threads should be equal to the number of
cores/concurrent hardware threads.

> 2. render each tile in that worker thread and join
> 3. clear the journal
>
> Front-to-back draws things from front to back in an opposite way that
> painter's model does. This is to avoid drawing invisible pixels which will
> be
> overwritten by the opaque front pixel. Am I right? Then IMHO it seems
> possible to skip drawing remaining pixels for a destination pixel after
> drawing an opaque pixel with OP where (x OP y) == x for opaque x.

This is correct, but there are some operations that are not possible
to do front to back, this would have to be annotated in the meta data
about the operations. There are various ways that rendering can be
skipped (reading back opacity, keeping track of fully opaque spans or
other forms of heuristics).

> I'd like to see how much memory bandwidth can be saved with front-to-back
> approach for real world applications.

Memory bandwidth is what is saved for solid fills, if you are doing
bilinear (or better) texture resampling or other more expensive
computations, the overdraw becomes even more expensive.

> And about hashes, how can you make it unique?

By accumulating changes to graphics state, path building and drawing
commands,. if the old journal was kept around as well, a proper
exhaustive check could be made rather than just comparing the hashes.
Doing this permits lazier implementation of canvases/scene graphs
since the renderer can discard repeated calls to draw the same
geometry (bailing out earlier or doing clipped redraws resulting in
less work earlier would of course be preferable.)

/Øyvind Kolås - Inter Open Source Technology Centre - London
--
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo