From: Keith P. <ke...@ke...> - 2004-05-17 20:17:30
|
Around 15 o'clock on May 17, Andy Ritger wrote: > Even for front buffered flushes I would be inclined to just say that it > damages the whole drawable, rather than try to compute a smaller bounding > region. That's certainly fine for now; if people really get excited about optimizing this case, they can fix it themselves. I don't know of too many applications which draw to the front buffer... > The tricky part here is that the damage event shouldn't be sent to > Damage clients until the hardware has completed the damage, but > that is the vendor's problem... I'm just trying to make sure > everything that is needed is in place so that vendors can solve that. It can't even be seen by the X server until the rendering is complete. When using 'automatic' update mode, there isn't an external application waiting for the event; the X server updates the screen directly. > One solution would be for the direct rendering client to send private > protocol to the X server as soon as the rendering is sent to the hw. Sure; just as long as the X server could then block awaiting completion. > BeginComposite/EndComposite bracketing would facilitate that (it > would be BeginComposite's job to make sure the hw had completed). There's no need for these extra requests -- the X server just needs to block when using the indicated source window buffer. This way, the X server can actually pend lots of other parts of the compositing operation and only when the affected window finally comes into play will the X server block. I just thought of another case here -- we want to allow for direct rendering compositing managers as well. That will require inter-client synchronization along the same lines... > glxgears is then redrawn (and swapped) before the compositing > is performed. When the compositing is performed, the xterm > and the portion of the glxgears window beneath the xterm are > recomposited into the backing pixmap, which is then blitted to > the visible screen. At this point, we have a tear between the > portion of the glxgears window that is not beneath the xterm > and the part that is (the part that is beneath the xterm is > from glxgear's new frame, while the part not beneath the xterm > is from the old frame). The window of vulnerability isn't as long as you fear -- the compositing manager can always use the damaged region of each window precisely at the time of the compositing operation, without reference to any events it has received. That's because the damage accumulates inside X server regions where it can be used to compute correct updates. As long as the compositing manager holds the server grabbed (which presumably locks out direct clients as well) while it updates the screen, there shouldn't be any tearing. No need to drain the event queue or anything else so dramatic. > > information related to a specific drawable. Any future requests for > > contents from that drawable must delay until that damage has actually > > occurred. > > Right, but how is that enforced? Who delays until the damage has > actually occurred? The X server would have to stall waiting for the swap to complete. It would "know" to do this because the direct client would have indicated that the swap was queued to the hardware. > True, but window managers can't cause video memory to be freed, > which would be really nice to do when you are transitioning into a > fullscreen application. They can free the extra buffers used for Composite, and the X server can migrate less used pixmaps from the video card. > Even the RandR implementation naively leaves the video memory allocated for > the largest possible root window size. Not in kdrive. > OK; how does a driver differentiate the per-window pixmaps from > regular pixmaps? The driver can see them associated with windows by wrapping SetWindowPixmap. > So if the X server might start compositing, then the driver can't advertise > the overlay port; is that correct? It could pretend the overlay port was busy for new apps and silently translate an existing overlay application to textures. I don't quite know; I use overlay video with composite now and it works as long as the windows are aligned on the screen correctly. I'd like to make that possible in the future as well, but I'm not quite sure how to do that. -keith |