[PATCH] Call flush callback chain when we flush client buffer due to overflow

[Kristian Høgsberg]

2010/7/29 Dave Airlie <airlied at gmail.com>:
>>> Also, there is one more call to FlushClient in CloseDownConnection; any
>>> reason we shouldn't be invoking the FlushCallback there too? More from a
>>> sense of completeness than a chance that it's going to actually matter.
>>
>> Yes, that sounds fine.  And I just realized that we need to change the
>> damageext handler to report damage after, so the batch buffer will
>> already have the rendering in it, in case writing the event overflows
>> the output buffers.  I'll roll these changes into an updated patch and
>> resend
>>
>
> Just from memory, we changed the damage reporting order before

Yeah, but not for the DamagePtr used by the damage *extension*.  The
damage module (miext/damage/) has a few internal users, such as sw
cursor, shadowfb and others.  I'm talking about changing the damage
extension reporter (damageext/) to queue up events after we chain to
the wrapped functions.  So it will only affect clients, but as it is,
damage events are typically sent out after the rendering happens
anyway (because of the order we normally flush client io buffers and
driver batch buffers).  Compositing managers relies on this order, and
there is no way we could reliably provide damage events to clients
before the rendering happens anyway.

Kristian