On 17/06/2024 18:09, Michel Dänzer wrote:
Can I know whether it is needed or not? Or should I be cautious and always do
it?
Assuming GBM in the X server uses the GPU HW driver, I'd say it shouldn't be
needed.
It does not (except the driver libgbm loads). We're trying to use this
in Xvnc, so it's all CPU. We're just trying to make sure the
applications can use the full power of the GPU to render their stuff
before handing it over to the X server. :)
A recording of the issue is available here, in case the behaviour rings a bell
for anyone:
http://www.cendio.com/~ossman/dri3/Screencast%20from%202024-06-17%2017-06-50.webm
Interesting. Looks like the surroundings (drop shadow region?) of the window
move along with it first, then the surroundings get fixed up in the next frame.
As far as I know, mutter doesn't move window contents like that on the client
side; it always redraws the damaged output region from scratch. So I wonder if
the initial move together with surroundings is actually a blit on the X server
side (possibly triggered by mutter moving the X window in its function as
window manager). And then the surroundings fixing themselves up is the correct
output from mutter via DRI3/Present.
If so, the issue isn't synchronization, it's that the first blit happens at all.
Hmm... The source of the blit is CopyWindow being called as a result of
the window moving. But I would have expected that to be inhibited by the
fact that a compositor is active. It's also surprising that this only
happens if DRI3 is involved.
I would also have expected something similar with software rendering.
Albeit with a PutImage instead of PresentPixmap for the correct data.
But everything works there.
I will need to dig further.
Regards,
--
Pierre Ossman Software Development
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linköping http://facebook.com/ThinLinc
Phone: +46-13-214600
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
