IEEE P1003.0 Draft 14 - November 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Functions available for User Preferences Management are: - Set and get preference data _S_e_r_v_e_r__C_o_n_n_e_c_t_i_o_n__M_a_n_a_g_e_m_e_n_t Functions available for Server Connection Management are: - Control access to the Server [add host to the access control list (ACL), list ACL, disable ACL] e - Connect and disconnect a client from a Server (and the display controlled by the Server) - Obtain Server implementation information - Flush output buffer to Server and wait for Server to process all events in the output buffer 4.7.4.1.2 Toolkit Window Services The Toolkit Window services provide a mechanism for runtime access to a library of visual objects. A visual object is a graphical display object (i.e., interaction object) with associated software that receives input from users (typically via a keyboard and a pointing device) and communicates with applications and other visual object software. The graphical representation of a visual object can be modified to reflect the results of application processing. Examples of visual objects are graphical push buttons, check boxes, and editing boxes. (Note: The term used within the X Window System community to define visual objects is ``widgets.'') Toolkit Window services are provided for two reasons: - To allow application software to directly utilize a visual object library - To allow application-specific visual objects to be created and added to the widget library (Note: creating a visual object includes writing software that uses the Toolkit services) Therefore, Toolkit services may be logically divided into two categories, with some overlap: Visual Object Interface Services, which are called by an application or dialog service, and Visual Object Programming Services, which are called by the visual object software. An application may use Toolkit Window services to: Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 141 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Perform toolkit initialization/exit - Set up visual object resources - Create/delete a visual object - Display a visual object - Add/remove application-specific routines to be called by a visual object (event callbacks) - Retrieve/modify the state of a visual object - Turn control over to the toolkit for user input processing A visual object software program may use Toolkit Window services to: - Manage child visual objects (a child visual object is a visual object that is displayed inside of another visual object) - Manage window events, timer events, and file input events - Handle visual object geometry (sizing, positioning, child visual object placement) - Handle user input - Manage visual object resources - Translate an event into an action - Manipulate graphics contexts - Manipulate pixmaps (pixel arrays--used to display a graphical object by turning pixels on and off) - Manage memory associated with graphical window systems - Handle errors associated with graphical window systems - Allow inter-visual object communication (via the selection mechanism) - Initiate other visual object routines (visual object event callbacks) - Initiate application-specific routines that have been associated with the visual object by the application (application event callbacks) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 142 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.7.4.1.3 Dialog Services Dialog services provide functions to support high-level graphical window system management for applications with the primary goal of delivering user inputs to the application program and application-driven information to the user. The dialog services allow for a separation of the user interface specifications from the application program. For example, there are many applications that are not concerned with whether a user entry object is a pull-down menu or a scrollable list. These applications are only interested in what the user specified or selected from the user entry object (i.e., the parameter value), which will then trigger some action by the application. To support this notion, a single dialog function might be specified for displaying a window made up of a composite of visual display objects, such as radio buttons, text key-in objects, and scrollable text lists. The application program does not need to manage or understand what the look, location, or visual feedback of any of these items will be. The dialog function has access to the presentation information required to display the specified window and it handles the display of the application specified window. Another dialog service would provide a high-level event loop that returns the user specified input as an application parameter value. The services provide simplicity over the degree of freedom available in Basic and Toolkit Window Services. Most User Interface Management Systems (UIMSs) provide dialog services to fulfill their requirement of separation of user interface from application software. These services are subdivided into: - Window services: provide services used to initialize the window service, create and delete windows with predefined associated visual objects, and manipulation of the pointing cursor. They include services that allow the application to communicate directly with the user via modal or modeless windows. - Visual object manipulation services: provide services used to access the graphical window system designed by the application designer, display the visual objects defined by the graphical window system, and associate them with application-tied inputs and outputs. - Event control services: provide services to allow the application to define a set of events and handle triggered events in one of two ways: +o Wait on the occurrence of any event, processing triggered events one at a time from an input queue (event-driven method) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 143 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS +o Attach to each event a function that is automatically executed when the event is triggered (callback method) 4.7.4.2 External Environment Interface Services These services provide support for the actual elements with which the user physically interacts. These functions provide services in three areas: - Graphical window system: provides definition of the presentation and behavior of the visual display objects, command language definition (syntax and semantics), specifications related to keyboards, selection devices, audio and video input/output devices. - Information Interfaces: provides specification of user resource data formats, containing presentation and action information pertaining to visual display objects. - Network Interfaces: provides protocol services for data transport, which is basically the bottom six layers of the OSI model 4.7.4.3 Interapplication Entity Services These services provide support for general conventions and specifications for interaction between graphical window system components. The services provide support for generalized network/multisession services, such as message handling between graphical window system components, intermediate language definition, and a standard definition of the format used for saving the presentation, behavior, and action information about graphical window system objects. 4.7.4.4 Windowing Resource Management Services These services provide general management functions across the graphical window system components, which include system administration-oriented functions (i.e., management of graphical window systems within the scope of the administrator, such as setting up defaults and user customization functions. For instance, it is important to allow reconfiguration and addition of terminals and displays without affecting the application interface.) These resource management services are independent from the OLTP Resource Management Services defined in 4.6.4.3. A standard definition of the format used for saving the presentation, e behavior, and action information about graphical window system objects e would provide a vehicle for exchanging graphical window system e information between software tools, such as User Interface Management e Systems (UIMSs) and Interface Design Tool (ITDs). e Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 144 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.7.5 Standards, Specifications, and Gaps Standards that relate to the user reference model presented earlier are considered here. Related standards that might be relevant for one or more of the interface components will also be mentioned. 4.7.5.1 Current Standards No current international or national standards exist for the graphical window system services, primarily due to the recent emergence of the windowing technology. However, several standard activities are underway and referenced under 4.7.5.2. Table 4-9 - Windowing Standards __________________________________________________________________________________________________________________________________________________ Service Type Specification Subclausee __________________________________________________________________________________e Basic Window Services G X Window System (X-lib) 4.7.5.3 e ee E ANSI X3K13.6 4.7.5.2 e ee Toolkit Window Services G X Window System (Xtk) 4.7.5.3 e ee E ANSI X3K13.6 4.7.5.2 e ee E IEEE POSIX.2 4.7.5.2 e ee E IEEE POSIX.1 {2} 4.7.5.2 e ee Dialog Services G - 4.7.5.3 e ee EEI Services E ANSI X3V1.9 4.7.5.2 e ee E ISO/IEC JTC 1/SC18/WG19 4.7.5.2 e ee E ANSI HSF-HCI 4.7.5.2 e ee E ISO TC159/SC4/WG5 4.7.5.2 e ee E P1201.2 4.7.5.2 e ee Interapplication Entity Services G X Window System (X protocol) 4.7.5.3 e ee Window/Character Resource G - 4.7.5.3 e ee Management Services e __________________________________________________________________________________________________________________________________________________ 4.7.5.2 Emerging Standards - ANSI X3K13.6. Currently developing an X Protocol standard. - ANSI X3V1.9. User-System Interfaces and Symbols: Working on a ISO/IEC Standard 9995, Keyboard Layouts for Text and Office Systems. Also working on the Voice Messaging User Interface Forum Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 145 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS (VMUIF). This is a mirror standards effort with ISO/IEC JTC 1/SC18/WG19. - ISO/IEC JTC 1/SC18/WG19. User-System Interfaces and Symbols. Working on developing standards for user interfaces and symbols associated with text and office systems. - ANSI HFS-HCI. Working on drafts on the design process, information presentation, forms-based dialogs, and window-based interaction. - ISO TC159/SC4/WG5. Software Ergonomics and Man-Machine Dialog: Working on developing parts of the ISO Standards 9241, Ergonomics of Visual Display Terminals. Their areas of concentration are software ergonomics, dialog principles, dialog styles, methods for evaluating software usability, coding and formatting of information, and terminology - IEEE P1201. Application and User Portability: Chartered to develop standards that facilitate application and user portability in the X Windows environment. P1201.1 is involved in defining a set of virtual toolkit services that would be independent of any windowing system. P1201.2 is involved in defining drivability guidelines. - ANSI CODASYL. Working draft available for Forms Interface Management Systems (FIMS), which covers the interface between a programming language and any form fill-in application on a computer or terminal screen. 4.7.5.3 Gaps in Available Standards There is a de facto standard for the base window system. The X Window System windowing protocol and the Xlib functional interface to the protocol were developed at Massachusetts Institute of Technology. Development is continuing under the aegis of the X Consortium, a group of interested parties in the computer industry and computer manufacturers. Relevant documents from the X Consortium are ``X Window System Protocol, X Version 11,'' ``Xlib - C language X Interface,'' ``X Toolkit Intrinsics - C Language Interface,'' and ``Bitmap Distribution Format 2.1.'' The X Window System protocol and functional interface are considered to be de facto standards in the base window system area because of their widespread adoption by major computer vendors and industry groups. Within the government, the National Institute of Standards and Technology (NIST) issues Federal Information Processing Standards (FIPS) that require purchases made by the United States Government to adhere to certain standards. NIST has adopted the X Window System Version 11 Release 3's X Window System protocol, Xlib, Xt Intrinsics, and Bitmap Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 146 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Distribution Format as FIPS 158. This is a noncompulsory (i.e., voluntary) standard. - Object Definition File Format: There are no standards addressing the format used for describing the ``look and feel'' of graphical window system objects. - Toolkit Services - Dialog Services - Interapplication Entity Services 4.7.6 OSE Cross-Category Services 4.7.6.1 Security The security aspects of graphical window systems and include: e - Authentication of person at login - Authentication of person when a service request is made to a client application - Provisions for visual labeling of sensitive material - Option selections available in support of sensitive activities - Prevention of moving data (cut/past) from a more protected security environment to a less protected environment 4.7.7 Related Standards Currently, the basic windowing services provide a certain level of graphics functionality, but the existing and proposed graphics standards (e.g., PHIGS, GKS) provide a much more comprehensive solution to graphic support. As the graphics and windowing technologies evolve, this distinction between the windowing and graphics services will continue to be blurred. For instance, proposals are already being developed that provide extensions to the X Window System that support 3-D graphics (i.e., PEX, PHIGS EXtensions), and implementations of GKS are currently available that use the X Window System to create the graphics. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.7 Graphical Window System Services 147 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS 4.7.8 Open Issues - Audio input/output - Video input/output - Security - Desktop. The Desktop, or graphical windowing shell, is a specification for the graphical window system work surface (i.e., the entire display screen). The desktop provides the user with a visual interface to available computer resources. A desktop may be characterized as a visual analog of the POSIX shell. It provides access to system resources, such as devices and files, and provides methods to start applications. Desktops typically also provide a set of often used utilities such as a calendar, a notepad, etc. The desktop is an important component of the look and feel of a graphical window system, but the current state of the industry is too immature for any standardization to materialize on a desktop specification in the immediate future. NOTE: There are some valid arguments for defining some requirements for standards at this level. The goal is to enable a user to easily go between application platforms and operate common functions in a similar manner. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 148 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.8 Graphics Services _R_e_s_p_o_n_s_i_b_i_l_i_t_y: _J_o_h_n _W_i_l_l_i_a_m_s 4.8.1 Overview and Rationale Graphics Services are key components and play an important role in the POSIX Open System Environment as it is used today in many different areas of industry, business, government, education, entertainment, and most recently, the home. The number of applications is growing rapidly, with increasing graphics capabilities. Some of these areas are user interfaces, computer-aided drafting and design, electronic publishing, plotting, simulation, animation, scientific visualization, art, and process control. The use of pictorial graphics provides a more intuitive interface and thus facilitates man/machine interaction. Graphics has become a routine part of most organizations today, ranging from hardcopy graphs and charts to user interfaces and complex 3-D visualizations incorporating video and sound. The graphics technology of rendering objects has become dramatically more realistic and hence is used by engineers, architects, artists etc., to enable them to see precisely what their final products, whether automobiles or buildings, will look and behave like under real-world conditions. Graphics has allowed dramatic improvements in the ``look and feel'' of user interfaces and the trend is towards increasing use of these interfaces to interact with computers graphically, via windows and icons and this reduces the time involved in learning to use a computer. Standardization of graphics services has many benefits for application developers, users, and systems integrators. The underlying motivations for considering graphics standards and their relation to the POSIX Open System Environment include: (1) Portability: In order to protect investment and achieve independence from a particular technology and a particular supplier of technology, portability at both hardware and software levels is necessary. There are many aspects of portability within graphics, all of which are potential money and time savers. - Applications portability - Graphics package portability - Host machine independence Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Graphics Services 149 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - Device independence +o input devices: dials, mouse, tablets etc. +o output devices: plotters, raster, vector etc. - Window system independence - Programming language independence - Programmer portability - User portability (2) Interoperability/Distributed Graphics: In order to allow applications to execute on one machine and display graphics on remote display servers, standard graphics protocols are necessary. This allows for display of graphics on machines that are incapable of executing particular types of applications and it also facilitates graphics conferencing. (3) Graphics Data Exchange: In order to share or exchange graphical information between diverse applications, standard graphics data exchange mechanisms are necessary. This clause presents a reference model for this component and describes the services provided to application programmers and users. It also describes the current national/international standards, emerging standards, de facto standards, and any existing gaps that need new standardization efforts. 4.8.2 Scope Included within this component are standards in the graphics area that address the following topics : - Application Program Interface (API) Standards - Language Bindings Standards - Metafile and Archive Standards - Device Independent Interface/Protocol Standards - Computer Graphics Reference Model - Conformance Testing of Implementations of Graphics Standards Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 150 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 - Distributed Graphics Standards - Imaging Standards - Performance Metrics Standards The standards not addressed here are: - Data Exchange Standards - Graphical User Interface Standards - Window Management System Standards 4.8.3 Reference Model Over the past decade many computer graphics standards have been developed. While they are similar in concepts, their underlying reference models are different. This restricts the degree to which the standards are compatible. By producing a reference model to which all future graphics standards are to adhere, compatibility of graphics standards is assured. Formal work on the Computer Graphics Reference Model (CGRM) standard is in progress within the ANSI X3H3.2 committee. It is an international standard that explains the relationships between existing graphics standards and defines relationships between standards in computer graphics and those in other areas. It will form the basis for the next generation of computer graphics standards. Broadly speaking, CGRM provides a framework within which relationships between standards can be described. There are five types of standards in the current family: - _A_p_p_l_i_c_a_t_i_o_n _P_r_o_g_r_a_m _I_n_t_e_r_f_a_c_e (_A_P_I) _S_t_a_n_d_a_r_d_s: These define a programming interface for application programmers. GKS, GKS-3D, PHIGS, and Xlib are examples of standards in this area. - _M_e_t_a_f_i_l_e _a_n_d _A_r_c_h_i_v_e _S_t_a_n_d_a_r_d_s: These standards define representations of graphics for storage and transfer between systems. These are basically file format and file transfer encoding standards. CGM (Computer Graphics Metafile) and PHIGS Archive files are of this type. - _D_e_v_i_c_e _I_n_d_e_p_e_n_d_e_n_t _I_n_t_e_r_f_a_c_e _S_t_a_n_d_a_r_d_s: These standards define the interface between device-independent graphics systems software and one or more device-dependent graphics device drivers. CGI (Computer Graphics Interface) is the standard in this area. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Graphics Services 151 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - _L_a_n_g_u_a_g_e _B_i_n_d_i_n_g _S_t_a_n_d_a_r_d_s: API and device interface standards are functional specifications defined independently from particular programming languages. Each standard has attached language binding standards that state how the functionality should be accessed from a variety of programming languages. - _F_r_a_m_e_w_o_r_k _S_t_a_n_d_a_r_d_s: These include the standardization of a reference model for computer graphics, conformance criteria, and the registration of graphical items. The CGRM describes the current family of graphics standards in terms of the following four levels of abstraction: - _A_p_p_l_i_c_a_t_i_o_n _L_e_v_e_l: This is the level at which applications-related information is composed into abstract graphics related to the application. - _V_i_r_t_u_a_l _L_e_v_e_l: At this level, the graphical output to be displayed is described in terms of output primitives - _L_o_g_i_c_a_l _L_e_v_e_l: At this level, the information necessary to render a primitive on a particular device is assembled. - _P_h_y_s_i_c_a_l _L_e_v_e_l: This level is associated with a particular output device and a collection of input devices. The physical level need not correspond to real devices such as a pen plotter. There could be further layers of the system between the physical level and the hardware, such as the window system. The Application Program Interface (API) is the interface between the application and the graphics system. There are also interfaces to metafiles and archives and to the operator. Here the operator need not mean human operator, but the user of the graphics system; for example, the window system. The Computer Graphics Reference Model can be incorporated into the POSIX OSE reference model as depicted in Figure 4-17. It provides the context for the discussion of graphics services and shows that the graphics services is a component of the overall POSIX OSE and is available to the the application through the POSIX OSE API. The entities and interfaces specific to the graphics services are identified in this clause. The entities are: (1) Application Software, such as CAD/CAM/CAE applications, imaging applications, electronic publishing, etc. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 152 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 _________________________________________________________________________ _________________________________________________________________________ Figure 4-16 - Computer Graphics Reference Model Level Structure (2) Application Platform, which consists of graphics libraries such as GKS, PHIGS and Xlib. (3) External Environment, consisting of external entities with which the application platform exchanges information such as input devices, X/PEX servers, hardware buffers, etc. The interfaces are: (1) Application Program Interface (API), which is the programming interface between the application and the application platform. It standardizes the conceptual model, calling sequence, functions, and syntax that a programmer uses to develop a graphics application. Each API standard has an attached language-binding standard that allows the functionality to be accessed from a variety of programming languages. A standard API in conjunction with a standard language binding promotes application portability, by isolating the programmer from most hardware peculiarities and providing language features readily implemented on a broad range of processors. Examples of APIs in the graphics services area are GKS, PHIGS, PIK, PostScript, etc. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Graphics Services 153 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-17 - POSIX OSE Graphics Service Reference Model (2) External Environment Interface (EEI), which is the interface between the application platform and the External Environment described earlier. In the graphics services area these can be device drivers that are used for communication between the device-independent and the device-dependent functions as well as protocols and file formats. The standardization efforts in the graphics area focus on these two interfaces. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 154 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 4.8.4 Service Requirements 4.8.4.1 Graphics Concepts Computer Graphics Services can be discussed in terms of the following fundamental graphics concepts: _O_u_t_p_u_t__P_r_i_m_i_t_i_v_e_s The output primitives are the building blocks used to construct graphical objects for display or storage in an archive file. Common output primitives are: - _L_i_n_e - _P_o_l_y_l_i_n_e used to represent a series of straight lines from a set of points. - _M_a_r_k_e_r is a special symbol used to represent semantics of graphical objects. - _F_i_l_l _a_r_e_a is an area with an edge and an interior which may be filled with a solid color or some form of pattern or hash. - _T_e_x_t is an output primitive used to represent strings in two or three dimensional space. - _A_n_n_o_t_a_t_i_o_n _t_e_x_t is text that is always displayed facing the viewer. - _C_e_l_l _a_r_r_a_y_s are areas with rectangular grids which can take on individual colors. - _T_r_i_a_n_g_l_e _s_t_r_i_p is a set of triangles defined by a particular ordering of vertices. - _Q_u_a_d_r_i_l_a_t_e_r_a_l _m_e_s_h is a set of quadrilaterals defined by a grid of vertices. - _S_u_r_f_a_c_e_s: NURBS (Nonuniform Rational B-Spline) - _C_u_r_v_e_s: NURBS (Nonuniform Rational B-Spline) - _C_o_n_i_c_s: Circles, ellipses, parabolas, and hyperbolas _P_r_i_m_i_t_i_v_e__A_t_t_r_i_b_u_t_e_s Attributes of primitives determine the style of the display of the primitive. For example, lines and edges may have different line styles such as dotted or dashed, text may have different fonts, orientation, and Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Graphics Services 155 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS character spacing. A polymarker may be an asterisk or a small triangle. They all may be red in color. General type attributes that apply to almost any output primitive are color, visibility, pickability, and highlight method. _I_n_p_u_t__P_r_i_m_i_t_i_v_e_s Input primitives or logical devices are virtual devices designed to insulate the application from the real input devices. Logical devices include picking devices, locator devices, choice devices, valuator devices, etc. In terms, of actual devices, a locator device might be associated with the first mouse button. _I_n_p_u_t__M_o_d_e_l The input model describes how input primitives and logical devices are related to physical input devices and the degree of control provided to the application over the devices. For example, one control choice might be how feedback is echoed to the operator when a logical locator device is attached to a depressed mouse button. The feedback might be a rectangular cursor or the highlighting of geometry as a cross-hair cursor moves over it. When the button is released the device coordinates are placed in the locator data record and an event is placed in an event queue for which the application can check asynchronously. The method the application uses to determine if a device has data for it is usually described in terms of modes. A common mode is event mode. The application waits a finite time for some event to appear in a queue. If no event comes in the finite time, the application does other processing and eventually comes back to check the queue with the wait for some event. If an event appears, the application determines what type it is and gets the data for that type of event. For a pick device, the data might be all possible graphical primitives that could intersect some aperture, possibly specified in the device coordinate system. _C_o_o_r_d_i_n_a_t_e__S_y_s_t_e_m_s__a_n_d__C_l_i_p_p_i_n_g Part of the graphics services is a means to utilize various coordinate systems. Graphical output has to be described to the graphics system in terms of some coordinate system, relevant to the application and presented to the display device in terms of its own coordinate system, the device coordinate system. It is unlikely that these two coordinate systems will be the same. A graphics system may therefore involve a number of coordinate systems and hence the need to define transformations between them. Some standard types of transformations are scaling, rotating, translating, reflecting, and projection, such as parallel and perspective. They are used to manipulate objects in a coordinate system and to map from one coordinate system to another. The coordinate systems commonly used are modeling coordinates, world coordinates, view-reference coordinates, normalized projection coordinates, and device coordinates. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 156 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 Clipping is the process of specifying a region in space and restricting graphical output to that region. Only those primitives that define objects in that region will have their output displayed. _O_u_t_p_u_t__M_o_d_e_l The output model is the concept of how graphics objects are created, displayed, and controlled on output devices. The output model defines how to position and organize objects on the screen, and the visual state of these objects such as visible or invisible, hidden lines removed or not removed, picture matches retained structure, picture not consistent with retained structure, etc. More specifically, the output model concept is made up of the: - Transformation pipeline - Rendering pipeline - Retained structures - Nonretained structures - Graphics state - Window systems e _S_t_o_r_a_g_e_/_A_r_c_h_i_v_i_n_g Storage data formats for displayed or rendered images are required, but e not treated at this time. e 4.8.4.2 Graphics Requirements The graphics service requirements of all users of this system can be generalized as: - The ability to create, delete, and modify output primitives. - The ability to specify and edit the primitive attributes globally and individually. - The ability to transform (i.e., scale, translate, rotate, reflect, project, etc.) primitives for construction of more complex objects and for arrangement in the viewing space. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Graphics Services 157 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS - The ability to create and manipulate a database of primitives, to define and edit attributes, to create and combine transformations, and to selectively control the display of graphics primitives. - The ability to display graphical objects constructed in a retained database, or the ability to display primitives immediately, or to display from both a retained database and immediately. - The ability to apply lighting and shading algorithms to collections of graphical objects with multiple light types and sources. - The ability to prepare display data and control the timing of the actual display of the display data. On some systems this is referred to as frame buffer control. - The ability to store and retrieve graphical objects from files. - The ability to control input devices and retrieve data from input devices. - The ability to direct output to a meta-file and retrieve graphics data from a meta-file. - The ability to inquire about all aspects of the graphics environment; e.g., the state of the system at any given time, the actual capabilities of a given hardware platform, the attributes and primitives supported by a given implementation, etc. - The ability to distribute graphics. - The ability to control errors. 4.8.4.3 Application Program Interface Services The major categories of graphics services available in the POSIX OSE API area include: - 2-D graphics API services - 3-D graphics API services - Device interface API services - Image processing API services For most of these API standards there exist standard language bindings so that applications using different programming languages can access the same functionality. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 158 4 POSIX Open System Environment Services ENVIRONMENT INTERIM DOCUMENT P1003.0/D14 The choice of which graphics standard API to use will depend on a number of factors: application profile, overall system architecture, equipment available, existing application database interaction, system performance considerations, user interface requirements, management policy, and other external factors. The aim of producing a compatible set of graphics standards in GKS, GKS-3D, PHIGS, PHIGS PLUS, etc. (described in the Standards subclause) is to allow that choice to be made in the most flexible way. 4.8.4.4 External Environment Interface Services The major categories of graphics services in the POSIX OSE EEI area include: - Protocols - File Formats - Device Drivers The choice of which standard to use depends on a number of factors: application profile, system architecture, equipment available, system performance considerations, and other factors e 4.8.5 Standards, Specifications, and Gaps There are several major standards existing in the computer graphics industry today, that have been approved by National/International organizations such as ANSI, ISO, and IEEE. There are also standards efforts going on in related areas such as application data exchange. These official graphics standards are complemented by de facto standards that have been accepted by the graphics industry at large. This document provides a general explanation of these standards, their specifications, and interrelationships. 4.8.5.1 Current Standards PHIGS -- ISO 9592 Parts 1-3 Fortran Language Binding -- ISO 9593-1 Ada Language Binding -- ISO 9593-3 C Language Binding -- DIS 9593-4 The Programmer's Hierarchical Interactive Graphics Standard (PHIGS) is a functional specification of the interface between an application program and its graphics support system. It is an ANSI/ISO standard and provides the following graphics Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4.8 Graphics Services 159 P1003.0/D14 GUIDE TO THE POSIX OPEN SYSTEMS _________________________________________________________________________ _________________________________________________________________________ Figure 4-18 - POSIX OSE Graphics Service Reference Model Standards functionality: - A high degree of interactivity - Multilevel, hierarchical structuring of graphics data - Easy modification of graphics data and the relationships among the data - 3-D, as well as 2-D, graphical input and output - Offline storage (and retrieval) of graphics data PHIGS controls the definition, modification, and display of hierarchical graphics data and specifies functional descriptions Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 160 4 POSIX Open System Environment Services