RE: [gtk-list] Re: XInitThreads causing problems to GTK windows.

["Peter Wilson" <peter stubble force9 co uk>]

> I have looked at your prog. It looks like the problem is in X,
> but who knows.
> Just don't use XInitThreads(), as it will slow down things
> additionally and
> gtk already takes care of that. But you have to call
> g_thread_init() before
> the call to gtk_init(). And then you have to call
> gdk_thread_enter() before
> any call to gtk/gdk-function and gdk_thread_leave() afterwards; not within
> signals, as they already hold the lock but also before gtk_main()
> and friends.
> You can af course put more than one gtk functions inside such a block.

Sebastian,

    I think you've missunderstood a little what I'm trying to achieve. The
second thread in my program will NEVER make any GTK+ / GDK or GLIB calls, so
g_thread_init is not needed. However, it may well be making calls directly
to XLib at the same time as GDK calls XLib, for this reason I NEED
XInitThreads(). The second thread in my program simply 'looks after' XLib
events for a window that the first thread creates (by opening it's own XLib
connection....). The second thread never changes any variables at all, so I
don't need any mutexs at all. For the moment though I'm just calling
XInitThreads AFTER gtk_init and hopeing that nothing bad happens (oh
god...). Actually - it probably doesn't matter - I don't currently call any
GTK / GDK functions while the second thread exists, but that isn't very
forward looking!

    For anyone who's interesting in what I'm doing... I'm porting an
application that was originally written under DOS with a very simple VESA
linear frame buffer library for graphics (that I wrote in assembler). All I
need is to be able to easily put images in windows, and full screen under
X - as fast as posible. I'm not bothered about dithering & changing
bit-depths etc as I know that all the machines that will ever run this
program will be in 32bit video modes. I looked into using something based on
a GdkImage, but bailed out since there's no documentation about it (yeah I
know the source is the best blah blah). So XLib it was. The system works
very well indeed (apart from the problems above) - I have a routine that
opens a window, and allocates a shared-memory image. I've then got a buffer
to write into and just XShmPutImage to put the image onto the screen. To
handle expose, map & unmap events I have a very simple second thread, it
simply responds to expose events with XShmPutImage's and exit's when a
destroy event is recieved. As for full screen use, I've decided that DGA is
a bad idea, I don't want to make the executable suid - so instead I simple
demand that the X server has a higher virtual resolution than the desired
full-screen mode and that the mode is available - so I then use XF86VidMode
extentions to set the mode, and move the viewport such that the window fills
the screen!

    If anyone's particularly interested in using this nasty kludge to get a
simplish frame-buffer like window set up then give me a shout - I'll clean
up the code, remove any unrelevant bits and release it LGPL for ya.


Cheers for now,


Chris Wilson [who really should setup Outlook so that his emails don't bear
his father's name ;]

cdw22@cam.ac.uk
Magdalene College, Cambridge.