On Sun, 2009-09-06 at 09:46 -0700, Jesse Barnes wrote: > On Sun, 06 Sep 2009 12:23:12 +0200 > Michel Dänzer <mic...@daenzer.net> wrote: > > > On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote: > > > I've been working on coding up the server and client side of > > > SGI_video_sync, OML_sync_control and SGI_swap_control. I came up > > > with this set of new protocol (against the dri2-swapbuffers branch) > > > to support the new requests. > > > > > > We still need to change the DRI2SwapBuffers request to handle the > > > various OML bits before it gets merged. > > > > > > To summarize: > > > DRI2GetMSCReq - get MSC triple > > > DRI2WaitMSCReq - wait on an MSC count or divisor/remainder > > > DRI2WaitSBCReq - wait on a swap count or all pending swaps > > > > Waiting in the X server will make it quite unlikely that the client > > will be notified within a reasonable timeframe from when vertical > > blank actually occurs. Won't this jeopardize the usefulness of the > > functionality? > > As they're mainly used for throttling drawing, I don't think so. But I > also don't see a way to avoid it. In the composited case, compositor > interaction will be necessary, and even for non-redirected windows, > the client doesn't know which CRTC it's on w/o racing with the server.
Waiting in the server doesn't solve the latter problem, does it? The window could move to another CRTC while it's waiting. > > > - compositor interaction; in the compositor case the display server > > > will be incrementing frame count based on compositor drawing > > > rather than vblank events > > > > I think that's a bad idea, as it will confuse apps if the compositor > > misses a frame or renders the app window more than once per frame. > > It seems to match what people want though; so far we've heard from > Soren and Robert and both want to know when the pixels are actually > displayed for various apps. W/o compositor interaction I don't see how > we can do that. I'm not arguing there should be no protocol between the compositor and clients, but I'm arguing that the frame counter probably isn't appropriate for this. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
