Application calling DRI2SwapBuffers twice without updating buffers
Jesse Barnes
jbarnes at virtuousgeek.org
Mon Sep 13 09:20:51 PDT 2010
On Mon, 13 Sep 2010 11:57:51 +0300
Pauli Nieminen <ext-pauli.nieminen at nokia.com> 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
More information about the dri-devel
mailing list