Application calling DRI2SwapBuffers twice without updating buffers

Application calling DRI2SwapBuffers twice without updating buffers

[Pauli Nieminen]

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. 

Pauli
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Application calling DRI2SwapBuffers twice without updating buffers

[Jesse Barnes]

On Mon, 13 Sep 2010 11:57:51 +0300
Pauli Nieminen <ext-pauli.nieminen@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