"micro-tiles" in LibArt

But maybe indeed they could also help to quickly reject tiles in a 
polygon, when that tile
is already drawn completely. Like if a tile is completely covered by a 
polygon/rectangle/circle,
it will be flagged. And primitives behind it do not need to render that 
part again, since it is already
completely covered by a higher level primitive.
Something like a rough pixel Z buffer (32*32 pixel ).
It seems libart is extremely fast in calculating the covered tiles by a 
polygon.
Maybe in the above case it might help to speed things up, while a real 
pixel-level z-buffer would not help.

>The primary purpose of the Z-buffer is removing
>invisible sufaces in 3D->2D projection.
>  
>
Right.

>If you use a pixel-level z-buffer you won't be able to
>increase the performance because it's much faster just
>to write a pixel rather than to check your Z-buffer
>and then make a decision. 
>
Certainly in case of writing pixels to a buffer, which does Agg.

>But the idea is to use a
>"span-level" z-buffer, that is to check the visibility
>only once for the whole span. Well, it's just a quick
>thought, very immature.
>
I don't think i know what a span is :-(
Something like spans in a polygon?

It is a very compact way of representing "dirty" areas,
which can either match exactly the real dirty surface,
or be larger than the real dirty surface.

If I remember properly, the whole surface is divided
into 32x32 pixel squares, where each is described by
a bounding box (stored as [x0][y0][x1][y1] in 4 bytes).

If only a single part of the square overlaps the dirty
surface, then the bounding box can code the smallest
rectangle which covers that surface. If there is more
than one overlap, then the rectangle will most probably
grow to fill the square.

LibArt is smart about handling this micro-tile array
and does a good job at extracting contiguous horizontal
strips which are covered by the micro-tile, thus allowing
the window refreshing code to repaint very quickly the
dirty parts.

See http://www.levien.com/libart/uta.html for a picture
showing how this all fits together...

You can easily check if a rectangle completely
overlaps another one. You can also easily intersect
two rectangles. But as for arbitrary polygons, you
will have to use CSG to calculate intersections and
unions, which is much more expensive.

BTW, what is the idea of "micro-tiles" in LibArt?

> >Still, this technique is widely used and
> >called "Z-buffer". :-)
> >
> I love to have it since in many chip design software
> this speeds up 
> drawing a lot i think..

The primary purpose of the Z-buffer is removing
invisible sufaces in 3D->2D projection.

If you use a pixel-level z-buffer you won't be able to
increase the performance because it's much faster just
to write a pixel rather than to check your Z-buffer
and then make a decision. But the idea is to use a
"span-level" z-buffer, that is to check the visibility
only once for the whole span. Well, it's just a quick
thought, very immature.