[PATCH 1/2] Always call the flush callback chain when we might send out damage events

[Kristian Høgsberg]

On Sun, Aug 1, 2010 at 3:20 PM, Keith Packard <keithp at keithp.com> wrote:
> On Sun, 1 Aug 2010 14:39:46 -0400, Kristian Høgsberg <krh at bitplanet.net> wrote:
>> Before this gets drowned out in janitorial patches... Keith, do you
>> want a pull request for this and the damageext patch?  Did you have
>> have a look at the damage change?
>
> I read through the change and reviewed the potential impacts on the
> server. I'm a little concerned about having the semantics of the damage
> extension accidentally change as the code paths for the post-activity
> damage region processing.

Half a sentence missing here?  The patch is not changing the
semantics, just making sure that the semantics that we effectively
provide and clients expect is what they get (post rendering
notification).  The order of rendering vs damage reporting doesn't
determine the order in which the client sees things, the order in
which we flush protocol buffers and submit batch buffers does.  And we
can't possibly provide pre-rendering notification to clients, that can
only work as a callback in the server.

> And, I'd love to have that code 'fixed' so
> that there wasn't additional region processing needed. So, it's not my
> favorite change, but anything additional seems like a riskier
> proposition for 1.9.
>
> So, I was planning to merge the damage change along with your other
> fixes for 1.9. It'd be lovely to get other people to take another look
> at the damage code to see if they can identify potential issues with
> your change.

Yup, it is the kind of change that requires a bit of review.

Kristian