[cairo] threaded, journaled software backend/rasterizer experiment

[Taekyun Kim]

This is exactly what I was thinking for a long time.
I haven't seen GEGL code but does GEGL also render its image graph in this
way? Maybe I shall have to see GEGL if so.

Anyway Let me check that I understand this correctly.

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
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.

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

 From my quick glance, cairo_surface_flush() and cairo_surface_mark_dirty()
seem to be taken care of to defence against outer modifications/access on
the buffer.

And about hashes, how can you make it unique?

Anyway, thanks for your work and I will also do some experiments.

--
Best Regards,
Taekyun Kim

On 09/23/2011 10:01 AM, Øyvind Kolås wrote:
> I've implemented a tiled/queue based vector-rasterizer experiment to
> explore rendering strategies and performance. The experiment can be
> useful to learn from perhaps some of this code could even find use in
> cairo.
>
> The antialiasing quality strives to be equivalent to 15x17
> supersampling. In addition to rasterizing bezier paths ◯ uses the
> equivalent of fragment shaders to compute source patterns like solid
> colors, linear and radialgradients and surface sources. (invert,
> brightness contrast, blurs and more could be implemented as more such
> shaders.) At the moment the code has to choose a pixel format to
> target, changing this to be 16bit or floating point requires swapping
> a couple of files.
>
> The code to be used with it's own state management or use a cairo
> surface as well as be driven from cairo, I wrote the code this started
> from for a memory constrained environment where I wanted a cairo like
> API.
>
> All path building, and painting commands (with source state snapshots)
> get journaled, when the scene is flushed (needs to be done if using
> the cairo surface as if it was an image surface and doing mid-render
> readbacks). Indexes for tiles are built up as the journal is written
> and only paths intersecting a tile gets an index written. The optimal
> tiles to render seem to be chunks of scanlines and not square
> rectangles, to avoid having to process the same set of edges during an
> active edge table rasterization pass. It is possible to store hashes
> of the journals relevant paths per tile, and avoid rerendering if the
> front buffer already contains the correct data, this is disabled by
> default. II haven't quite worked out how to best to front to back
> rendering for portions of the commands in the journal yet.
>
> Core utilzation seems to be quite good when rendering, for a single
> core rendering cairo's image backend with pixmans optimizations is
> quite a bit faster, but that should be expected given its used of
> SIMD.
>
> The code is available at http://pippin.gimp.org/git/cairo/log/ the git
> repository there provides both a cairo surface wrapping the rasterizer
> and some tests that drive ◯ directly.
>
> /Øyvind Kolås - Intel Open Source Technology Centre, London
> --
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110924/f7ce6251/attachment.htm>