I think I prefer signal handlers for dirty regions like the APIs Søren orignally proposed.
Basically the same as a GSignal for mark_dirty_area().

I don't even think it'd be hard to support - we'd start by just marking the operation's extents we compute anyway as dirty - and it's a much more flexible API than counting some "operation" on a surface.

I haven't seen Søren's proposal, link? The serial approach has the advantage of being trivial to implement and zero-overhead...

Agree a signal is more flexible, but it would have to cover all changes, not just "external" changes like mark_dirty does now.

how are you going to do signals in cairo? (have to say: once you're adding signals the gobject reinvention is getting painful. signals are pretty hard, too, if you handle all the weird reentrancy cases only Tim Janik can keep track of)

A damage-based API could be nice. Would probably want to allow multiple damage regions per surface, like

damage* damage_create(surface)
damage_reference(damage)
damage_destroy(damage)
region* damage_subtract(damage)

you could also put a callback here like:
 damage_set_notify(damage, callback, data, dnotify_data)

rather than trying to do a full "signal system" 

fwiw, this is overkill for the two cases I had in mind (detect when to copy cairo pixels to gdkpixbuf pixels; detect when to update a server-side copy of an image surface). The cache invalidation serial is totally fine for cache-expiration purposes.

But I can imagine uses for damage too. For example an incremental image loader could just hand a surface to something like GtkImage and have things magically work. (GtkImage would get damage as new pixels arrived.)

I also like a serial change API.  I'm more interested in having one on cairo_t though.  My usecase is that in pango entry points, I want to quickly check the serial to see if the font matrix / options / ... may have changed on the context.  Only if the context has changed I want to do the heavier query on all those stuff.

After thinking about this for a bit I like the idea of a damage API on surface, if you have a Damage object per subscriber then each subscriber gets their own damage region and the only overhead in cairo_surface_t could be one pointer for the head of a list of Damage objects. Also you avoid worrying about generic signals (callback lists) since each Damage object could just support a single notifier function.

For cairo_context_t it seems like you'd get into what "counts" as a change ? Maybe you end up wanting the equivalent of a damage object:

 CairoContextChanges { 
    unsigned int matrix_changed : 1;
    unsigned int font_changed : 1;
    // ... etc. 
 }

cairo_context_changes_t* changes_create();
changes_reset()
changes_get_matrix_changed() // changed since reset
changes_get_font_changed()

and just like surface damage object, have a changes_set_notify().

Maybe both surface and context "change trackers" should be named the same,
cairo_surface_changes_t
cairo_context_changes_t

or

cairo_surface_damage_t
cairo_context_damage_t

just thinking out loud.

But yeah, the change serial is definitely a lot simpler and gives you a global "are caches invalid?" flag that's already useful.

This only adresses the original "callback when surface content changes", but you can (ab)use cairo_surface_set_mime_data() to get a callback when a surface is modified.

An example for this can be found here: https://bugzilla.mozilla.org/attachment.cgi?id=624394&action=diff

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/308.