On Mon, 13 Sep 2010 11:57:51 +0300 Pauli Nieminen <ext-pauli.nieminen@xxxxxxxxx> wrote: > Hi, > > It is possible for client to call DRI2SwapBuffers twice in row even tough > client should update back buffer in between. Problem is exposed when > application does stupid thing like: > > renderScene(); > glXSwapBuffers(); > /* Might be long delay between but no rendering */ > glXSwapBuffers(); > > glx and egl specifications don't say anything if driver may fail in this case. > Only relevant part is that the back will hold undefined content. Second swap > will results front buffer holding undefined content. Which makes me think that > specification makes above code application error only that shouldn't be > detected. > > Is ddx driver allowed to fail the swap in this case? > > There is some special case when application doesn't have any back buffer. > Hardware limitation forces driver to share buffers between applications. Too > bad sharing causes that new application might takes over the back buffer > between swaps. > > The special case where there is no valid back for client because client > failed to render between swapbuffers has to fail either silently or with error. > I would prefer to return error that is mostly likely ignored by application. > > Should driver fail all swaps that would result to the front buffer to have > completely undefined content? > > There could be simple detection for the application trying to show random > content. This would catch a few trivial application errors that would cause > corruption in screen. > > Detecting application errors (if it can be done cheaply) would help application > developers understand that their code is causing problems. > > If driver is utilising invalidate events detection can't happen in server > side. We could print a warning in this case at the very least. Maybe if we try to swap again with the same dri2 invalidate stamp we could print an error. Kristian? Jesse -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
