# To subscribers of the xforms list from spl@eggshell.ucsd.edu :
> I need to update a drawing quicly, and so not to do it within
> the quite slow (cause it's a big app :)) fl_check_forms() routine.
I don't understand why the size of the application would affect the
speed of fl_check_forms(). It only responds to X events when they
occur, otherwise it returns control to the application. Why would you
say it's slow?
> I'd like to let a subprocess - let's say a thread - draw in my
> glcanvas. obviously, this seems to be a problem...
Why?
As far as threads and the GLcanvas go, if you're just updating the
canvas itself, then I don't see a problem -- as long as you have the
proper GLXContext, you should have no difficulties. For example, in
an application of mine I create texture maps, polygons, and display
lists in a background thread and use them in the main thread with no
problems.
Since the GLcanvas is basically just an X Window with not much in the
way of embellishment, you should be able to do whatever you want to it
from a thread.
X itself and, hence, XForms can also be multithreaded through
functions which were added several years ago in X11R6 but that doesn't
seem to be an issue here.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 09:44:48 EDT