On Tue, 08 Sep 2009 10:37:38 +0200 Michel Dänzer <mic...@daenzer.net> wrote:
> 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. It does make it easier to either ask for a new event or block the cliprect update until we get the event. If we ended up blocking all the time we could just move the wait to the client though. > > > > - 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. It seemed like a natural fit to me since the compositor really is determining the application frame rate in the redirected case. But you're right that it could end up being a variable frequency counter. Existing apps may not handle that very well, I'm not sure. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ 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
