[PATCH 4/5] glx: Implement GLX_PRESERVED_CONTENTS drawable attribute

[Tomasz Lis]

I agree with Ian's proposition to add integer counter which replaces
hard-coded index. This also allows to add:

assert(i <= sizeof(attribs)/sizeof(attribs[0]))

While both GLX 1.4 spec and older GLX_SGIX_pbuffer do not mention what
value to return if GLX_PRESERVED_CONTENTS is unset on creation, they
clearly indicate that the new buffer should behave as if
GLX_PRESERVED_CONTENTS was = True:

"

If this (GLX_PRESERVED_CONTENTS) attribute is not
    specified, or if it is specified as True in <attrib_list>, then when a
    resource conflict occurs the contents of the pbuffer will be preserved
    (most likely by swapping out portions of the buffer to main memory).
"

I don't think this code returns apps settings, i think it is always used to
query a specific buffer (but I may be wrong).

2013/3/1 Adam Jackson <ajax at redhat.com>

> On Thu, 2013-02-28 at 13:55 -0800, Ian Romanick wrote:
> > On 02/25/2013 02:04 PM, Adam Jackson wrote:
> > > We back pixmaps with pbuffers so they're never actually clobbered, so
> > > we're really just recording the value passed in at create time so that
> > > you get the same thing when you query.
> >
> > Is that actually right?  There are some cases where they query returns
> > the actual state, and there are some cases where the query returns the
> > apps setting.  I haven't checked to see which this is.  In Mesa, we've
> > taken to quoting the spec in cases like this.
>
> If the spec had anything to say about the matter, I would happily quote
> it.  Unfortunately GLX is much less rigorous about this than GL.  My
> reply to Eric was based on a careful reading of GLX 1.4.  While it's
> clearly within the law to treat all pbuffers as preserved, the spec is
> silent on whether the queried attribute value reflects the value given
> at pbuffer creation.
>
> - ajax
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130307/c0eb8679/attachment.html>