[cairo] API proposal: Damage Tracking

[Soeren Sandmann]

"Gerdus van Zyl" <gerdusvanzyl at gmail.com> writes:

> Would it not be too slow with many objects since cairo needs to
> compute the geometry to extract a rectangle?

The profiling I have done of my little demo/test app (so take with a
grain of salt) does show that even with pure software compositing,
tessellation is the main hotspot, and given how cairo is currently
implemented, damage tracking would require tessellating.

However, I am pretty confident this can be fixed, one way or the
other:

- The tessellator could be made faster.

- Computing covering rectangles could likely be done quite a bit
  faster than computing exact trapezoids.

- We may stop tessellating all together, and directly rasterize
  polygons.

If all else fails, the application can still choose to maintain a
bounding box for particularly complex items, while computing the
damage dynamically for others.

> Something related I would really like is
> cairo_end_damage_tracking_mask that returns a hit mask for
> intersection testing (eg. mouse click).

The main concern I would have with a bitmap, is memory use. If you
have a lot of canvas items, and each one needs to store a couple of
bitmaps for hit testing, a lot of memory could be needed. Also, if you
have a very big item which consists mostly of empty space (like say a
frame around a page), you would get a very large bitmap with a whole
lot of 0s in it.

A simple answer to that may be some form of compression, say with some
variation over quad trees. In any case, I don't really have a better
answer than bitmaps, and I do agree that we need better tools for hit
testing.

If we were to go with a (compressed) bitmap, what I would need is just
something like this:

        bitmap_t *cairo_fill_bitmap (cairo_t *cr);
        bitmap_t *cairo_stroke_bitmap (cairo_t *cr);

Ie., tracking would not be required for me. 

> I have always though cairo could do with a semi-official separate minimal
> scenegraph since the above scenario is so common.

I think it would to be difficult to do something that is both minimal
and useful to a lot of applications, while not depending on a toolkit.


Thanks for the comments,
Soren