Putting a pixmap into a window every frame

[Andrew Bainbridge]

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?

Thanks again,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20210823/d3810665/attachment.htm>