2010/7/29 Dave Airlie <[email protected]>: >>> 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 _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
