On Wed, 2018-05-09 at 18:17 +0200, Michel Dänzer wrote:
> On 2018-05-08 09:47 PM, Adam Jackson wrote:
> > dri*_bind_context, when switching current drawables, will drop the
> > reference on the old one; since that refcount has probably now gone to
> > zero that means we lose all the state we applied to that drawable
> > before, like when swaps are expected to complete.
> > 
> > Dropping this reference might make some sense for drawables that aren't
> > _ours_, since we don't get events for destroyed resources and need to
> > rely on the server throwing errors when we name a no-longer-valid
> > drawable. But if the resource is one that this client created, we can be
> > reasonably sure that it will be explicitly destroyed by the same client
> 
> Is there any mechanism in place for this to result in
> loader_dri3_drawable_fini actually getting called when destroying a
> window without using glXDestroyWindow?

No; there's not a way to hook XDestroyWindow, and we can't ourselves
listen for DestroyNotifys. In fact even closing the display wouldn't be
 enough, though I think that's true with or without this patch.

> > @@ -449,6 +450,8 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable 
> > glxDrawable)
> >        return NULL;
> >     }
> >     pdraw->refcount = 1;
> > +   if ((glxDrawable & dpy->resource_mask) == dpy->resource_base)
> 
> Should this be
> 
>    if ((glxDrawable & ~dpy->resource_mask) == dpy->resource_base)
> 
> (Negated dpy->resource_mask)? Otherwise this fails to take effect for me
> here with glxgears:

Argh, yes. Too used to being on the server side where you have
clientAsMask.

> How about the idea I described before, saving the loader_dri3_drawable
> values in a hash table in dri3_screen? Maybe we could simply save a
> pointer to the whole struct, after only freeing the renderbuffers.

That would also leak, less in absolute terms but the same big-O, for
the same reasons.

- ajax
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to