>> window till the expose event handler is finished - if there are still >> random bits there when it does, then its your fault, AFAIK. > >My sincerest apologies - I've only had contact with the GTK materials for >a couple of days. In that time I've found the documentation wanting, >especially given that this is supposed to be a portable API and therefore the >programmer picking it up won't necessarily have been weened since birth on >the inner workings of X.
Sorry, I didn't mean "its your fault" in that way. The problems you have seem to be related to the glwidget, which by my understanding is not part of the GTK+ distribution. It would appear from this message from Ralph Walden ---------------------------------------------------------------------- Make sure that you're calling glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ---------------------------------------------------------------------- that the glwidget itself may not 100% obey the "rules" for GTK+, and may change some of the semantics that would be associated with, say, a GtkDrawingArea. >Really? That's a shocker. Now then, could you please tell me why I can't >fire off a command to redraw the gl widget to remove the random data in memory >that the gl widget visualizes, before that widget has the chance to interact >with the user? Apparently because the glwidget's design and/or implementation is messing this up. You would not get the behaviour you describe with other low level GTK widgets. I've never used the glwidget, but I've used DrawingArea, the Canvas and EventBox widgets a great deal, and they don't operate in the way you describe the GL widget doing. Again, you seem to have interpreted some of what I wrote as an admonission that you're doing the wrong thing. I didn't mean that at all, and I apologize for this impression. --p _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
