Received: from D0SFB.FNAL.GOV by d0sgi3.fnal.gov via SMTP (951211.SGI.8.6.12.PATCH1042/940406.SGI) for id IAA09590; Fri, 12 Jul 1996 08:44:36 -0500 Date: Fri, 12 Jul 1996 8:44:33 -0500 (CDT) From: "Oh drat these computers! They're so naughty and complicated I could just pinch them. (Marvin the Martian)" To: lueking Message-Id: <960712084433.2180061b@D0SF24.FNAL.GOV> Subject: Thoughts on the D0 GUI from the viewpoint of the event graphics From: UAZHEP::SHUPE 11-JUL-1996 20:54:37.84 To: @GUI.DIS CC: Subj: Thoughts on the D0 GUI from the viewpoint of the event graphics July 11, 1996 Dear fellow GUI subgroup members, I was on vacation in the Bahamas when the GUI subgroup formed and had its first meeting, so I will try to play catch-up a bit and offer my thoughts on some of the issues pertaining to Run II graphics. The graphics thin layer package, GRAF, currently calls OpenGL, GL, and X11 (and soon NT graphics) to do its graphical operations. In OpenGL and GL it makes use of the full 3d power of these languages. In X11 and NT it offers best approximations to the fancier graphics effects. Currently, the working output formats are Postscript and HPGL, and others, such as VRML and Autocad DXF are under development. As provided by vendors, these commercial screen graphics languages are provided with Fortran and C entry points. GRAF is written in Fortran, though C callable entries could be made available if there is a need. So far there is no great push in the direction of C++ in the space of commercial languages, though it is beginning to appear, and I believe is used internally in the new Direct-X protocol appearing this year in the "internal" graphics driver space of PC's. In any case, the PC journals keep characterizing OpenGL as the best route to platform independent 3D graphics, and this is why the graphics group went with this standard. GRAF is cleanly partitioned, so that drawing and attribute (color, style,...) routines are separate from transformation routines, which (except for the final device transformation) are in turn separate from the windowing routines. This latter separation is encouraged by the OpenGL standard, which is not committed to any particular windowing system. However, this disconnect between a graphics language and the window system creates a funny situation when it comes to the user interface. SGI GL (full 3D graphics, just like OpenGL) and X11 (2D graphics library), both include full specifications for interaction with the keyboard and mouse. Event handling is a bit different in the two systems. GL and X11 both have event queues for these devices which may be polled, but one often finds in X11 Motif programs that events are handled by callback to handler routines for each type of event. OpenGL doesn't have any event handling routines in its specification. For example, when using OpenGL in a multi-windows Motif environment, we pick currently pick up the GLUT library from SGI (which operates on MANY platforms). GLUT has a standard Motif style callback structure, which means that it has a BACKGROUND LOOP! So if other frame facilities we are considering also have callback structures of their own, then it seems to me that we could easily find ourselves in the battle of the background loops. [Surely this problem is more general than the issue of graphics. Has anyone else run into this problem of competing main programs? Is there a clever solution?] The current "solution" to this potential background loop problem is to cut the background loop in the GLUT main routine and turn it into a routine which gets polled for events (triggering callbacks). So all versions of GRAF (OpenGL, GL, and X11) currently have polled event queues which should be compatible with any frame, even if it has a background loop of its own. Of course a better solution would be to somehow handle all events with a unified scheme. Leaving the issue of event handling, we could ask what graphics manipulators GRAF currently uses and which ones might be handy if they were available. In order have all the interactive options which are available in a system such as the Aleph DALI displays, one needs a tight connection between the graphics viewer and the mouse. By "graphics viewer" I mean something like a scientific visualization frame or VRML browser which has easy viewpoint, lighting, color, and other attribute manipulation. If there are menus and manipulators (sliders, dials, rotors, etc) available in the frame GUI, then it is convenient to work with these as the mouse interface. Aleph DALI does not use any such manipulators. It has a number of viewpoint and selection manipulations interfaced by directly detecting cursor motion and mouse button states. Actions are selected by typed command (one or two character). This command interface is difficult to learn and use, but once the actions are invoked, the mouse manipulations are elegant and powerful. In the current GRAF package, the attempt is to keep the best of two worlds by realizing all the mouse manipulation features available in Aleph DALI, while providing a command interface consisting of main menus and popup menus. Presently, the menus themselves, shaded buttons and all, are drawn by menu routines which are themselves other GRAF routines. But again, this has been done in a modular fashion so that the whole menu interface could be replaced by the new D0 frame GUI. Likewise, some of the motion manipulations which are currently controlled Aleph-style by cursor position and mouse button states could be replaced by sliders, rotors, and other manipulators of the frame GUI. But some operations, such as "grab" motions or "rubber banding", have no manipulator equivalent, and we will always need to be able to read mouse, and conceivably keyboard, events directly from the GRAF routines to preserve interactive capability. So I am asking my fellow subgroup members to keep several things in mind while shopping through the several frame GUI's under consideration. At the very least: (1) What is the event handling structure, and how might it complement or collide with event handling in the graphics sector? (2) What is available in the way of manipulators which might be useful for viewpoint and attribute manipulation? (3) Can a tight connection be allowed between mouse and keyboard actions and the graphics routines which need the information "instantly"? There are two extreme program configurations we might keep in mind which help clarify these issues: I. The "tightly coupled" representation: The graphics routines have all event handling piped through the frame GUI. No features intrinsic to the commercial graphics language are utilized to pass mouse or keyboard information. II. The "uncoupled" representation: When the frame GUI detects that the user wants to view an event, it passes all mouse and keyboard control to the graphics viewer routine. When the user is finished viewing the event, control is passed back to the frame. The graphics routines themselves are responsible for all graphics manipulators. It may be that the optimal solution lies somewhere between these two extremes. Creative thinking is needed here! Cheers, Mike Shupe