Personality Neutral Graphics Subsystem

The present invention relates to computer graphics, and in particular to a personality neutral graphics subsystem which supports the graphics needs for a computer system which runs programs written for several different types of graphical user interfaces on the same desktop.

The past decade was a revolutionary time in computing. The advent and proliferation of personal computers has transformed the computer environment from one of large mainframe computer systems which was highly centralized and tightly controlled, to a network of interconnected personal computers and workstations which are often widely distributed yet easily accessible via computer networking.

Concomitant with this change in computer environments is the significant change in the way a user interfaces with the computer. In the past, the display of information on the screen was primarily alphanumeric. In addition, commands such as operating system commands (e.g., DOS commands) were input through a keyboard to control the computer. These commands were often archaic and difficult for users to understand and work with, particularly nontechnical users, without first investing significant amounts of time to learn the commands.

A revolution in computing occurred when the graphical user interface (GUI) was introduced. This user interface is displayed on the monitor to the user, and as its name suggests, is primarily graphics oriented. Rather than typing commands into the computer via a command line, the GUI allows users to control the operation of the computer via the manipulation of icons and dialog boxes displayed on the monitor within a region referred to as a "window." Each icon represents a functional task which the user can select for execution by simply clicking on the icon. The term "window" is well known in the art, and is generally a rectangular region on a computer display, which receives user inputs and displays output.

GUIs generally include a window management system which creates, destroys, minimizes and maximizes windows on the display screen, places the control bars (e.g., a scroll bar) and title bars, and controls the Z-ordering and clipping of the various windows on the display screen. The window manager creates a window in response to a request from an application program, and allocates a region on the display for the window the application program can use to present information on the display. Often times, the display of the computer system having a plurality of windows is referred to as a "desktop" with each window seemingly representing a piece to paper lying on the desktop.

To draw within a window, GUIs generally also include a graphics engine which draws lines, circles, points, and generally controls how data is presented on the display.

The first personal computer to gain widespread commercial acceptance for the GUI was the Macintosh.RTM. personal computer by Apple Computer, Inc.

Based upon the popularity of the GUI for the Macintosh and its obvious advantages such as its user friendly nature, GUIs quickly gained widespread acceptance.

Software developers for IBM compatible personal computers also introduced GUI products. The first widely used GUI for IBM compatible personal computers (hereinafter "PCS") was WINDOWS.TM. developed by Microsoft Corporation (MS). WINDOWS runs on top of the DOS operating system and provides a "shell" (i.e., an interface) between the application program user and the operating system which allows a user to control the execution of an application program(s) by pointing and clicking with a pointer device (e.g., a mouse or trackball) on the screen. Due to the market acceptance of the WINDOWS GUI, application program vendors moved quickly to introduce products into the market which operated with the WINDOWS GUI. IBM also introduced a new operating system known as OS/2.RTM. which included its own GUI referred to as PRESENTATION MANAGER.TM.. In order to use OS/2 and its GUI PRESENTATION MANAGER, application program vendors had to update their products to operate with PRESENTATION MANAGER so the application program could display information on the screen.

As different GUIs entered the market, compatibility became a problem since each GUI had its own application programming interface (API), and its own functions an application program would call to interface with the GUI. The API calls generally fall into two categories 1) windows related, and 2) graphics related. With a GUI, the application program no longer has direct control over the display; the application program simply passes information and commands to the GUI via API calls, and the GUI issues the necessary commands to a graphics engine to display the information on the screen. Therefore, an application program written to operate with a certain GUI was limited to operating with only that GUI.

As an example, if an application program was written to execute with the OS/2 PRESENTATION MANAGER graphical user interface, it could not be executed on a computer running the WINDOWS graphical user interface since the API calls were different. Hence, application program vendors have had to supply different versions of their application program for each GUI. Take for example a typical application program, where a user has to choose between the DOS, WINDOWS or PRESENTATION MANAGER compatible version of the program.

In an attempt to resolve this problem, IBM introduced a version of OS/2 which allowed application programs written for GUIs other than PRESENTATION MANAGER to execute using the PRESENTATION MANAGER graphical user interface. This version was designated OS/2 Version 2.1 Special Edition and it allowed an application program, such as the word processing package Microsoft WORD 6.0 for WINDOWS, to be run on the PRESENTATION MANAGER GUI. This version of OS/2 also included the capability that multiple windows could be displayed on the screen simultaneously, wherein each window may contain information from applications written for different GUIs.

A problem with this earlier IBM approach was that it required that WINDOWS be loaded and resident in RAM. Therefore, in order to have the flexibility to run non-OS/2 based applications using the PRESENTATION MANAGER GUI, the user had to execute both WINDOWS and OS/2 PRESENTATION MANAGER. This was a costly solution since it required that the user have both OS/2 and WINDOWS resident and operating on the computer. In addition, this approach required a large amount of code. If a user was running several windows on the screen, each of the windows used the graphics engine associated with the graphical user interface with which the window was associated. As an example, if a user was running a first application program written to operate with MS WINDOWS and a second application program written to operate with OS/2 PRESENTATION MANAGER, then a first graphic engine compatible with MS WINDOWS would be required to write into the first window, and second graphic engine compatible with OS/2 PRESENTATION MANAGER would be required to write into the second window.

It would, therefore, be desirable to provide a common graphics subsystem which includes a GUI personality neutral graphics engine which services a variety of different GUI personalities running together on a single desktop.

An object of the present invention is to allow application programs written for different graphical user interfaces to be executed together on a single desktop.

Another object of the present invention is to provide a personality neutral graphics engine capable of interfacing with application programs written for various graphical programming interfaces.

Yet another object of the present invention is to provide a common graphical programming interface which allows application programs written for other graphical user interfaces, to be imported and seamlessly executed on a desktop controlled by the common graphical user interface.

Thus, in accordance with the present invention, a personality neutral graphics system resident in a computer operating system provides a personality neutral graphics interface between a graphical user interface and a graphics engine. The graphics system includes a common graphical user interface (CGUI) which receives graphics related application programming interface (API) calls from the application programs and transforms the various types of API calls native to a particular graphical user interface (GUI) into a format compatible with the personality neutral graphics interface. The transformed API calls are then passed from the CGUI to a personality neutral graphics engine that services the calls in cooperation with personality neutral device drivers thus allowing a single graphics engine to support the graphics needs for application programs which operate with different GUIs.

To handle the graphics API calls associated with the various types of GUIs supported by the CGUI, the CGUI includes a plurality of GUI specific graphic front-end interfaces, each associated with a particular type of GUI, such as OS/2 PRESENTATION MANAGER MS WINDOWS, X-WINDOWS.TM., etc. . . , and which each receive graphics API function calls from application programs written for that particular type of GUI. Each GUI specific graphic front-end interface receives the API call from a corresponding GUI and transforms the GUI specific personality neutral API calls.

The CGUI also includes a plurality of graphics back-end interfaces which are each associated with one of the GUI specific graphic front-end interfaces. Each graphic back-end interface converts the call received from the graphic front-end interface into a format compatible with the personality neutral graphics engine and passes the transformed calls onto the graphics engine. The graphics engine is personality neutral since the application programming interface between it and each of the plurality of windowing back-end interfaces is the same.

The present invention allows application programs written for a certain graphical user interface to operate on a computer running with a different graphical user interface. As an example, the PRESENTATION MANAGER GUI which runs on top of the OS/2 operating system may be modified to incorporate the personality neutral graphics system of the present invention so the resultant modified GUI can display information for various application programs written for other GUIs such as WINDOWS , X-WINDOWS, Macintosh or other known graphical user interfaces.

An advantage of the present invention is that users can now use a single graphical user interface and operating system to execute application programs written for different graphical user interfaces.

In addition, the architecture of the graphics management system reduces the code required to implement a personality neutral graphics system, and enhances the reuse of code in the system.

Another advantage of the present invention is, using a single graphics engine to support the graphics needs of multiple GUI personalities obviates the need for display and printer manufacturers to provide separate drivers for each GUI personality the device will operate with. The single graphics engine allows a single device driver to be used independent of the GUI the computer system is running.

These and other objects, features and advantages of the present invention will become more apparent in light of the following detailed description of a preferred embodiment thereof, as illustrated in the accompanying drawings.

FIG. 1 is a block diagram of a personal computer system;

FIG. 2 is an pictorial illustration of multiple windows displayed on a viewing device using a single graphical user interface;

FIG. 3 is a functional block diagram of a personality neutral window/graphics system; and

FIG. 4 is a more detailed functional block diagram of the personality neutral graphics manager shown in FIG. 3.

Referring now to FIG. 1, a personal computer system 20 includes a central processing unit (CPU) 22 (e.g., PENTIUM.TM., POWERPC.TM., etc. . . ), ROM 24, RAM 26, and an I/O adapter 28 which are all interconnected via a system bus 30. The system also includes a keyboard 32, trackball 34, mouse 36, and a speaker 38 which are interconnected in a well known manner to the bus 30 via a user interface adapter 40. To present information to the user, the system includes a display adapter 42 which may, for example, be provided as a super video graphics adapter (SVGA) card. Display adapter 42 receives commands and data to be displayed via the bus 30 and displays the data on a monitor 44 such as a CRT or a flat panel display. The system also includes a communications adapter 46 which allows the system to be interconnected to a LAN or WAN.

The computer system 20 executes a software operating system (e.g., OS/2) which in a well known manner provides centralized resource management for the CPU, memory, mass-storage devices, I/O devices such as the keyboard, display and mouse and the communication interfaces. The operating system generally includes a kernal, device driver routines and dynamic link libraries which with the application programs indirectly interact through a graphical user interface (GUI). The operating system may be provided, for example, as a multi-tasking operating system which allows views of several applications to be simultaneously displayed within their own window on the monitor 44.

In accordance with the present invention, computer system 20 includes a single graphical user interface (GUI) and operating system capable of executing application programs written for different graphical user interfaces. This allows users to adapt application programs written for various graphical user interfaces between different computer systems.

As an example, FIG. 2 illustrates a typical display screen 49 viewed on the monitor 44 (FIG. 1). In this particular example, display screen 49 includes two windows 50, 52. Each of the windows 50, 52 represent information from different application programs being executed by CPU 22 of computer system 20 (FIG. 1). The application program running within the first window 50 may be a word processing application written for the MS WINDOWS GUI, while the application program running within the second window 52 may be a spreadsheet application written for UNIX.RTM. based X-WINDOWS. Of course, many other applications are capable of being run in the windows 50,52, and those of ordinary skill in the art will recognize of course that more than two windows may be displayed on the display screen 49.

Referring now to FIG. 3, a personality neutral windowing/graphics system 80 which controls windows (e.g., windows 50,52 in FIG. 2) and information displayed within the windows on the display 44 is shown.

The personality neutral windowing/graphics system 80 receives graphics API function calls from a plurality of application programs generally denoted 82. The application programs 82 may include for example, a first application program 82a written for the OS/2 PRESENTATION MANAGER GUI while a second application program 82b may be written for the MS WINDOWS 3.1 based GUI. A third application program 82N being run by the computer system 20 may be written for the X-WINDOWS graphical user interface. Other application programs 82 which cooperate with particular GUIs may of course also operate with system 80. Thus, each of the application programs 82 cooperates with one of a plurality of different GUIs.

Application programs 82 issue API calls to perform a graphic function on display 42. Typical graphics API calls include calls to draw lines and circles and perform area fills within windows being shown on the computer display 42. Since each of the application programs 82 is compatible with a different GUI and each GUI has a different API call format, then each of the API calls provided by each of the different application programs 82 has a different API call format.

The graphic API calls are provided to a common graphical user interface (CGUI) 86. CGUI 86 receives the graphic API calls fed thereto and translates the different graphic API calls into a format compatible with a graphic engine 100. CGUI 86 also includes a personality neutral event/window manager 88 (PNEM) and a personality neutral graphics manager (PNGM) 90.

The personality neutral event window manager 88 receives windowing API function calls from each of the application programs 82, and creates, destroys, and processes the windowing related API calls. Such windowing API calls are provided having a format corresponding to the format of the GUI specific to the application program which originated the call. The event manager 88 then translates the GUI personality specific API call into a generic API call which is routed to a common event/window management server 92.

The details of the event/window manager 88 and the personality neutral windowing system are described in co-pending patent application entitled "Personality Neutral Window Management Subsystem" filed on even date herewith having named inventors Kenneth W. Borgendale, la M. Holland, Kelvin R. Lawrence, Colin W. Powell and Richard L. Verbug, identified as IBM attorney docket number BC9-94-134 assigned to the assignee of the present invention and incorporated herein by reference.

The personality neutral graphics manager 90 receives graphics API function calls native to a particular GUI and translates them into a generic graphic API call format. The translated calls are then passed to the graphics engine 100 which draws lines, circles, points, and generally controls the manner to which data is presented on display 45. The model for the translated API's may be X-WINDOWS APIs and the Gpi (graphics) functions from the OS/2 PRESENTATION MANAGER GUI.

Referring briefly to FIG. 4, the personality neutral graphics manager 90 includes a plurality of personality specific GUI graphic routines 94a-94N generally denoted 94. Each of the personality specific GUI graphic routines 94 is associated with one of the GUIs which is supported by the CGUI 86 (FIG. 3). GUIs supported by the CGUI 86 may include OS/2 PRESENTATION MANAGER, MS WINDOWS, X-WINDOWS, Macintosh and other known GUIs. If the CGUI 86 was capable of executing application programs written for five different types of GUIs, CGUI 86 would include five personality specific GUI routines 94 for translation of GUI specific graphic API calls to a format compatible with graphics engine 100 (FIG. 3).

Each personality specific GUI graphics routine 94 includes a GUI specific graphics front-end interface 95a-95N generally denoted 95 which receives the personality specific graphical API calls from the application program(s) 82 (FIG. 3) and decodes the calls to determine the specific lower level calls necessary to perform the graphical tasks associated with the particular API call. The calls are then passed to a corresponding one of a plurality of GUI graphics back-ends 96a-96N generally denoted 96 which translates the GUI specific commands into personality neutral graphic API calls which are sent to the graphics engine 100.

Returning now to FIG. 3, graphics engine 100 corresponds to the drawing engine for the system and also manages display resources such as colormaps, bitmaps, etc. The engine 100 provides an interface between the graphics transportation protocols and presentation (e.g., display) and printer device drivers 102, 104. The graphics engine 100 also represents the funnel to the various pieces of hardware.

The engine 100 is provided as a single, extensible graphics engine and thus avoids problems in the prior art of arbitration access to the display. The engine 100 also provides all of the device-independent functions currently required to be implemented in presentation and printer device drivers, including full image rasterization.

It should be noted that the interface between each of the GUI graphics back-ends 96 and the graphics engine 100 is the same, and hence "personality neutral." That is, although the graphics commands provided to CGUI 86 are specific to a particular GUI graphics routine the graphics commands provided from the PNGM 90 to the graphics engine 100 are independent of the GUI for which the application program was written and thus may be referred to as personality neural. This technique allows a single, common graphics engine to provide the appropriate functions for each of the GUIs with which system 80 is compatible. Thus the personality neutral graphics engine 100 of the instant invention performs all the system drawing in a manner which is transparent to the application programs.

Prior art techniques, on the other hand, use multiple graphics engines each of which supports only one of the GUIs which the system can run.

The interface between the CGUI 86 and the graphics engine 100 should be preferably selected to have a high degree of commonality with existing GUIs such as PRESENTATION MANAGER, WINDOWS, X-WINDOWS and Macintosh. As such, a preferred graphics engine is the graphics engine used in the OS/2 2.1 operating system currently available from International Business Machines, the assignee of the present invention. This ensures that GUI developers who wish to modify their GUI to work with the common graphics engine will be able to retain some of the code from their current GUI design.

The graphics engine 100 translates the graphics API command and in a well known manner issues the appropriate commands to device drivers 102,104 associated with the particular type of display 44 and printer 45 connected to the computer system 20 (FIG. 1). Device drivers 102, 104 then issue hardware specific commands to an operating system microkernel 106 which provides the necessary commands to the display 44 and printer 45.

A feature of the architecture for the personality neutral graphics system of the present invention is that the graphics engine 100 is modular and both extensible and replaceable. That is, as more powerful graphics engines are developed, including 3-D graphics engines, those engines can be used as the graphic engine 100 and each of the back-end interfaces 96 would be modified to accommodate the change in graphics engines.

In an alternate embodiment, the invention may be implemented as a computer program product for use with a computer system. Such implementation may comprise a series of computer useable instructions either fixed on a tangible medium, such as a computer readable media, e.g. diskette 142, CD-ROM 147, ROM 24, or fixed disk 152 (FIG. 1), or transmittable to a computer system, via a modem or other interface device, such as network adapter 110 connector to the network 120 over a medium 121, which can be either a tangible medium, including but not limited to optical or analog communications lines, or use wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer instructions embodies all or part of the functionality previously described herein with respect to the invention. Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including, but not limited to, semiconductor, magnetic, optical or other memory devices, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, microwave, or other transmission technologies. It is contemplated that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation, e.g., shrink wrapped software; preloaded with a computer system, e.g., on system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Internet or World Wide Web.

Although the present invention has been shown and described with respect to a best mode embodiment thereof, it should be understood by those skilled in the art that various other changes, omissions and additions to the form and detail thereof, may be made therein without departing from the spirit and scope of the invention.