<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0} p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Great reply. Thanks for taking the time.<br></div><div><br></div><div>Carsten Haitzler wrote:<br></div><blockquote type="cite" id="qt" style=""><div>I now can only talk<br></div><div>about mine and it does NOT do the above. There is a parent frame window but it<br></div><div>is identical in size to the client. It's just used for control. The<br></div><div>frame/border is drawn inside the compositor itself...<br></div></blockquote><div><br></div><div>Very sensible. If other people here know if other WMs work this way, I'd be interested to know.<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>even with Xpresent, you will be doing a copy from your<br></div><div>X(shm)Putimage to the pixmap, THEN presenting that pixmap (maybe will be<br></div><div>another copy - details above). So on a best case basis you have just as many<br></div><div>copies as going directly to the window, at worst it may be 2x the copies.<br></div><div>Admittedly the copies here will probably be on-GPU as opposed to the PutImage<br></div><div>which will be a CPU -> GPU copy. So there still may be a copy and this still<br></div><div>may have tearing happen<br></div></blockquote><div><br></div><div>This is the paragraph that straightened out all my misunderstandings. Thanks!<br></div><div><br></div><div>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?<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>In theory you could allocate your own DMABUFs and use DRI2 protocol - software<br></div><div>render into the mmaped dmabuf then show it like opengl does.<br></div></blockquote><div><br></div><div>Sounds like a fun challenge. I might attempt that one day.<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>As for waiting for compositor to be ready - you can't do that. You don't know<br></div><div>when the compositor will consume your pixmap and updates and even if it will<br></div><div>consume it at all. It may choose not to update/render your window (it's hidden,<br></div><div>it may be dropping down to only rendering every 4th frame or something). The<br></div><div>best thing for you to do is either render with a fixed timer (eg at 60hz) do<br></div><div>that on your side, open /dev/dri/card0 and try get vblank events (use libdrm to<br></div><div>do this), or probably a bit better is to use the xpresent (XPresentNotifyMSC()<br></div><div>to request events for screen refreshes).<br></div></blockquote><div><br></div><div>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. :-(<br></div><div><br></div><div>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.<br></div><div><br></div><div>Is there a reason xpresent events would be better for me than the vblank event?<br></div><div><br></div><div>Thanks again,<br></div><div>Andy<br></div><div><br></div></body></html>