Re: [xine-devel] OpenGL plugin checkin - Part 2: xine-lib changes

[Matthias H. <ma...@ms...>]

> > > > Now for the changes to xine-lib that might affect others:
> > >=20
> > > > I added another GUI_SEND message type:
> > > > XINE_GUI_SEND_WILL_DESTROY_DRAWABLE
> > >=20
> > > > This should be send immediately *before* a drawable is destroyed,=
 so that
> > > > the plugin can clean up anything connected to that drawable. It i=
s not used
                                                                     ^^^^=
^^^^^^^^^^
> > > > so far, but there's code present in the OpenGL plugin that will b=
e
        ^^^^^^
> > > > triggered by this message.
> > >=20
> > > Is this needed where you send XINE_GUI_SEND_DRAWABLE_CHANGED then d=
estroy the
> > > previously selected drawable?
> >=20
> > The gui should
> >=20
> > a) send XINE_GUI_SEND_WILL_DESTROY_DRAWABLE
> > b) destroy the drawable
> > c) if continuing (not exiting) create a new drawable
> > d) send XINE_GUI_SEND_DRAWABLE_CHANGED
>=20
> I don't know the code and how this message is currently used, but would=
n't it be nicer if the Gui would first send the DRAWABLE_CHANGED message =
and then if it succeeded destroy it?

As mentioned above, this message is new and not used at all so far. No,
it wouldn't be nicer. I need one message before the drawable is
destroyed and one after the new one is created. And personally I think
DRAWABLE_CHANGED implies there is a new drawable available.

There is no option 'if it succeeded'. Closing something must always
succeed. If not, xine may exit, closing it anyways.

> > I have to destroy the OpenGL context, and can only do that if the
> > drawable still exists.
> > At least I got tons of segfaults if I destroyed  it without attaching=
 a
> > (NULL) context to the drawable. This was with the old plugin, but
> > nevertheless the clearer way to do it is this way.
>=20
> Hmm... Did you do glMakeCurrent(context, null) before destroying? And e=
ven more important, did you do glFinish before all this?

Yes, I *would* set the current context to null if I could (that is, it
is done in the code path that is not yet called because no gui sends
this message so far).
glFinish() is not necessary. This must be implicit:

glXMakeCurrent:
'Pending commands to the previous context, if any, are flushed before it
is released.'

Hm. Now I discover I haven't read the specs completely:

glXDestroyContext:
'If  the  GLX  rendering  context  ctx is not current to any thread,
glXDestroyContext destroys it immediately.  Otherwise, ctx is destroyed
when it becomes not current to any thread.  In either case, the resource
ID refer=E2=80=90 enced by ctx is freed immediately.'

So I guess I *could* use glXDestroyContext even without
XINE_GUI_SEND_WILL_DESTROY_DRAWABLE, the last implementation
reproducably crashed when I did that, but it wasn't thread-aware, thus
it could be easily a problem related to threads.

I guess I will try using glXDestroyContext even when I did not get a
XINE_GUI_SEND_WILL_DESTROY_DRAWABLE. Let's see whether this works.

CU

Matthias

--=20
Matthias Hopf <mh...@su...>      /--       /--  /--         mat@mshopf.=
de
Maxfeldstr. 5 / 90409 Nuernberg    \-\  | |  \-\  |--         www.mshopf.=
de
Phone +49-911-74053-715            --/  \_/  --/  \--  labs