[PATCH xserver] damage: Add screen func called before damage event delivery

Keith Packard keithp at keithp.com
Fri Sep 16 15:51:11 UTC 2016


Michel Dänzer <michel at daenzer.net> writes:

> I'm afraid I'm not sure this is going in a good direction.

Yeah, with the WriteToClient changes from a few months ago, I think we
need to do something though. We used to be able to rely on no events
being delivered before the BlockHandler was invoked. That's no longer true.

> At the very least, the damage and glamor parts should be split into
> separate patches.

That seems reasonable enough.

> Does FlushClient get called after every DamageExtNotify call? Otherwise,
> some of the GPU flushes performed by DamageFlushDrawable will be wasted,
> hurting performance.

The driver gets told which drawable is being affected, so it could limit
flushes if there were no rendering operations affecting that pixmap. I
didn't add that code as it wasn't necessary to fix the bug.

> I don't like glamor hooking into this automatically, because it means
> the Xorg driver can't know whether or not glamor needs to be flushed.
> The Xorg driver needs to flush glamor for other reasons as well, e.g.
> for DRI2/3.

The lower level driver could wrap the function if it likes; glamor
certainly needs to flush at this point, so if the lower level driver
also has work to do at that point, it could.

> FWIW, this will do nothing for GPU screens. I'm not sure whether or not
> GPU screens need to be flushed for damage events, what are others'
> thoughts on that?

The immediate need here is for applications which use DRI to access
window pixmaps. As GPU screen pixmaps can also be directly accessed
through DRI, I suspect they would also need these hooks, but I guess I
don't understand why that wouldn't already be the case here?

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160916/e85a8a86/attachment-0001.sig>


More information about the xorg-devel mailing list