Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Patent
1996-10-11
1998-09-01
Katbab, A.
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
G06F 300
Patent
active
058016961
DESCRIPTION:
BRIEF SUMMARY
The present invention relates to data processing systems that are arranged to run a plurality of applications, each application being associated with one or more windows.
In such systems the windows are under the control of user interface software which is, amongst other things, responsible for controlling the output shown to the user on a display device of the system. The user interface software may be a separate entity from the operating system installed on the data processing systems (eg as in Microsoft Corporation's Windows product which runs on a DOS operating system), or can be included as part of the operating system itself (eg as in IBM Corporation's OS/2 operating system). For the purposes of the present invention it does not matter which type of user interface software is being used, and both of the above types will be referred to hereafter as graphical user interfaces (GUIs).
Today's GUIs generally exhibit a problem in handling user interface events. Most GUI systems take input events from devices such as the keyboard or mouse and place them on a queue. Some systems, eg IBM OS/2, Microsoft Windows, place all user events onto a single queue for the whole system; these systems will hereinafter be referred to as `synchronous` event handling systems. The manner in which such a synchronous event handling system handles messages is illustrated in FIG. 1. In the system shown, three applications are being used, namely applications A, B and C (items 10, 20, 30 respectively). Application A has three windows associated with it, Application B has one, and Application C has two windows. The user of the system will interact with the applications 10, 20, 30 by using input devices such as a keyboard or a mouse to direct input to the various windows being displayed on the display device of the system.
As events from the various input devices are received by the system, they are placed on a queue 40 which operates in a first-in-first-out (FIFO) manner. A piece of software, which shall be referred to herein as a dispatcher 50, then reads an event from the queue 40, determines which application the event is directed to, and dispatches the event to that application for processing. Once the application has processed the event, it informs the dispatcher 50, and the dispatcher then repeats the process of reading the next event from the queue 40, and sending it to the application that is perceived as being the application to which the event was directed by the user.
The dispatcher 50 has access to data giving information about the current location on the display device of the various windows of each application. Hence, if a particular event is from a pointing device such as a mouse, the positional information contained within that event can be used by the dispatcher 50 to determine which window is currently at that position, and hence which application should receive the event. Typically, if the next event has no positional information, for example if it represents a character input via a keyboard, then it will be considered by the dispatcher as being directed to the same application as the previous `pointing` event, and will be dispatched accordingly.
One major problem with such synchronous systems is that an application can potentially lock up the whole system by incorrect handling of an event. If, for example, the application does not inform the dispatcher that it has processed an event directed to it then the dispatcher will not continue to dispatch any further events that are building up in the queue 40. This could happen, for example, if the application gets into a situation where it cannot complete processing of the event directed to it.
As mentioned earlier, the dispatcher 50 can only deal with the next event on the queue once it has confirmation that the previous event has been processed. This can cause problems since the locations of windows on the display screen can change over time, and any significant processing delays can have the result that, by the time the dispatcher 50 comes to deal with a particular e
REFERENCES:
patent: 4896290 (1990-01-01), Rhodes et al.
patent: 5455904 (1995-10-01), Bouchet et al.
patent: 5495566 (1996-02-01), Kwatinetz
patent: 5524198 (1996-06-01), Matsumoto et al.
patent: 5533180 (1996-07-01), Zhou et al.
Pietrek, Matt, "Investigating the hybrid windowing and messaging architecture of Chicago," Microsoft Systems J., V9, N9, p. 15(14), ,1994.
Prosise, Jeff, "What's in a thread?" PC Magazine, V14, N21, p. 379(3), 1995.
Ruley, John, "NT and OS/2 Go Head-to-Head," Windows MAgazine, N501, P262, 1994.
Petzold, Charles, "Windows and Multitaskin," PC Magazine, V12, N13, p. 399(4), 1993.
Petzold, Charles, "Why you need to multitask in OS/2 presentation Manager?" PC Magazine, V9, N9, p. 293(4), 1990.
IBM: "OS/2 2.0 Presentation Manager Programming Guide," Mar. 1992, QUE, USA.
Grehan, Rick, "In Any Event," BYTE, May 1990, pp. 311-322.
Grosser George E.
International Business Machines Corp.
Katbab A.
McConnell Daniel E.
LandOfFree
Message queue for graphical user interface does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Message queue for graphical user interface, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Message queue for graphical user interface will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-274545