Putting a pixmap into a window every frame
andy at deadfrog.co.uk
Mon Aug 23 13:34:58 UTC 2021
Great reply. Thanks for taking the time.
Carsten Haitzler wrote:
> I now can only talk
> about mine and it does NOT do the above. There is a parent frame window but it
> is identical in size to the client. It's just used for control. The
> frame/border is drawn inside the compositor itself...
Very sensible. If other people here know if other WMs work this way, I'd be interested to know.
> even with Xpresent, you will be doing a copy from your
> X(shm)Putimage to the pixmap, THEN presenting that pixmap (maybe will be
> another copy - details above). So on a best case basis you have just as many
> copies as going directly to the window, at worst it may be 2x the copies.
> Admittedly the copies here will probably be on-GPU as opposed to the PutImage
> which will be a CPU -> GPU copy. So there still may be a copy and this still
> may have tearing happen
This is the paragraph that straightened out all my misunderstandings. Thanks!
In one of Keith Packard's presentations, he shows a modified xeyes using the Present extension to draw without tearing. But I think he says compositing is disabled. I thought this was just because it was a work-in-progress demo. But you are telling me that even now the system is fully implemented, the Present extension gives no guarantee of tear free rendering if there is a compositor. Have I got that right?
> In theory you could allocate your own DMABUFs and use DRI2 protocol - software
> render into the mmaped dmabuf then show it like opengl does.
Sounds like a fun challenge. I might attempt that one day.
> As for waiting for compositor to be ready - you can't do that. You don't know
> when the compositor will consume your pixmap and updates and even if it will
> consume it at all. It may choose not to update/render your window (it's hidden,
> it may be dropping down to only rendering every 4th frame or something). The
> best thing for you to do is either render with a fixed timer (eg at 60hz) do
> that on your side, open /dev/dri/card0 and try get vblank events (use libdrm to
> do this), or probably a bit better is to use the xpresent (XPresentNotifyMSC()
> to request events for screen refreshes).
If I understand correctly, here you list a bunch of reasons I should get the compositor to tell me when it wants a frame, and at the same time you tell me it isn't possible. :-(
At least it means I don't have much work to do - my library already does XPutImage() and waits for the vblank event as you describe. I just need to add the SHM interface.
Is there a reason xpresent events would be better for me than the vblank event?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg