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
