[Kwintv] Re: OpenGL view mode and a new threading solution

[Dirk Ziegelmeier]

On Sunday 06 June 2004 23:58, Koos Vriezen wrote:
> You wrote:
> > On Sat, Jun 05, 2004 at 05:02:29PM +0200, Koos Vriezen wrote:
> > > On Sat, Jun 05, 2004 at 01:04:27PM +0200, Dirk Ziegelmeier wrote:
> > > > Another solution for the threading problems in kdetv may be a
> > > > "XInitThreads()" call in main.cpp. It works fine, only OpenGL freezes
> > > > at widget creation. Also, I found many places in the net where
> > > > problems with this call are described; even Qt does not call it by
> > > > default. Does anyone have experience with it?
> > >
> > > I use it in kxineplayer (kdeextragear-2/kmplayer/src/xineplayer.cpp).
> > > According to XInitThreads man page, it only works if all threads use
> > > the X(Un)LockDisplay and not some other mutex for accessing the
> > > display. (which also means that the grabber thread and Qt still
> > > excluding each other accessing the display) What are exactly the
> > > "threading problems" btw.
> >
> > The ones you fixed. I don't like the usage of the Qt lib mutex, because
> > all QDialog::exec() calls block video display due to recursive
> > acquisition of the Qt lib mutex (there are still a few remaining). And
> > the shutdown of the V4L plugin is quite a hack. When I use
> > XInitThreads(), it looks like I do not need XLockDisplay(), the app seems
> > to work just fine (as long as I don't create Qt events from the other
> > thread). Only OpenGL has problems.
>
> Don't know, sounds again replacing one hack with another (and also
> potential dangerous, these X(Unl|L)ockDisplay are not there for nothing).
I wouldn't consider making XLib thread-safe a hack... I'd call it a clean 
solution (much cleaner than qApp->lock()).

> About the shutdown, IIRC there wasn't a shutdown procedure for plugins.
> Have you tought about changing the plugins API for such a procedure.
There is, you can create and delete all plugins (this is what in fact is done, 
e.g. when you change from a xv to a v4l device). The problem is the app 
shutdown, last time I checked it, Qt deleted the app WITHOUT acquiring the Qt 
lib mutex, and this is what made the app crash. I hacked around it by using 
SIGNAL( aboutToQuit() ) to shut down the plugin.

> Alternative, there could be a central QThread registration that could be
> waited for on shutdown. I disagree the shutdown hack would justify the
> XInitThreads change ...
That could work, although this is more ugly than anything I tried before. I'll 
do some experiments again.

BTW, finally managed to get my f****** Radeon drivers to work (SuSE provides 
fixed packages). They are quite crappy (XV support is broken), but I can 
watch TV in OpenGL mode with 1% (read: "one") CPU load (kdetv + X, Athlon 
2000, Radeon 9500Pro). Cool ;-) However, the plugin always crashes at 
shutdown. I had the opportuinty to check it at a friend of mine with an 
NVIDIA GFMX400 card, it worked stable with it, but he had 11% CPU load 
(Athlon 2400).

Dirk