Using the standard Motif drawing area widget with OpenGL has some extra caveats. The main caveat is that you must create the top level widget with the correct visual for the program's OpenGL rendering.
When you start a widget program, there is generally a call to XtAppInitialize to establish the connection to the X server and create the top level widget. Both steps are done in the same routine. So how can we call glXChooseVisual to know what visual the top level widget should use until we have established a connection to the X server?
It would appear that it is impossible to create the top level widget with an appropriate visual for OpenGL. XtAppInitialize connects to the X server and creates the top level widget, but it does not realize the top level widget. The X window for the top level widget is not created until XtRealizeWidget is called. This allows XtSetValues to be used after the top level widget's creation (and before its realization) to specify the widget's visual. The paperplane sample code in the non-OpenGL widget case demonstrates this.
A second caveat is due to the X Toolkit's inconsistent inheritance
of the visual, depth, and colormap widget resources. The default visual of a widget's window
is copied from its parent window's visual.
But the default colormap and depth of a widget
are copied from the widget's parent widget.
This means that if you create a widget derived from the shell widget and the widget's parent uses a non-default depth or colormap for a non-default visual, you will need to specify the same visual as the new widget's parent widget. If you do not, a BadMatch X protocol error will result. For this reason the paperplane example's XmCreatePulldownMenu calls specify the visual of the created widget's parent widget in the Motif drawing area version of paperplane.
Realize that it is not possible to bind an OpenGL rendering context to a widget's window until the widget has been realized. Until the widget is realized, the widget's window does not yet exist. Notice paperplane does not call glXMakeCurrent until after XtRealizeWidget has been called.
To see how the 3D viewing area widget fits into the paperplane widget hierarchy example, Figure 2 shows the complete hierarchy including widget class names.
These caveats are not unique to OpenGL. The problem comes from using non-default visuals with the X Toolkit. PEXlib 5.1 programs have a similar need for non-default visuals and require the same jumping through hoops[1]. Fortunately, if you use the OpenGL drawing area widgets, you can avoid the caveats of using the standard Motif drawing area.