Windows-type operating systems allow users and developers to interact with software applications via a consistent graphical user interface (GUI), while at the same time providing them with the ability to interact with multiple software applications simultaneously. Ideally, an operating system should provide access to as much of the underlying graphical hardware's capabilities as possible while maintaining a consistent API (application program interface). An operating system API is the set of routines, protocols, and tools that make up the interface between the operating system and the software applications that access it. Any interaction between a software application and the operating environment (i.e. video display, hard drive, keyboard, etc.) Is done through the operating system API.
Additionally, the operating system should support a degree of feature transparency. That is, a software application should be able to benefit from a system feature without requiring the software application to be aware of every detail of the system feature. For example, a software application designed on a system with a 16 bit colour depth display should run as intended on a system with a 32 bit colour depth display. The software application should not need to know the supported colour depth of the video display it is running on. The greater the degree of feature transparency provided by an operating system, the greater the ease of developing software applications that can run in a variety of environments and the greater the selection of software applications available to use with any given platform.
Video Memory, Video Surfaces and Layers
Personal computers and other computing devices generally include a circuit board referred to as a graphics card, video, card or video board, which allows the personal computer to drive a physical display such as an LCD (liquid crystal display) or a CRT (cathode ray tube) monitor. These graphics cards typically contain their own video memory, so that the computer's RAM (random access memory) is not needed for storing video display data. Many graphics cards also have their own on-board microprocessor so that the processing required to render graphics can be performed very quickly and without being a burden to the main microprocessor of the computer.
Graphics cards typically have much more video memory than needed to store the contents of a single display screen. The contents of the video memory is partitioned into chunks which can be dynamically defined and redefined, each chunk having a specific width, height and other characteristics. Each chunk is referred to as a video “surface”, one of these video surfaces being treated as the primary display. Drawing to the video surface associated with the primary display will yield visible graphics on the physical display. Drawing to video surfaces other than the primary display will not be visible unless the contents of those surfaces are “blitted” to the primary display's video surface.
“Layers” hardware allows a graphics card to have one or more video surfaces as part of the primary display. The way the various video surfaces are combined and/or blended to create the primary display is configurable via the layers hardware on the graphics card. The layers hardware combines all the surfaces targeted at the primary display non-destructively. That is, the contents of the various video surfaces are not affected by the layering hardware—only the end result visible on the display device is affected. This makes graphics cards with layering hardware ideal for low performance platforms that require sophisticated graphics composition such as automotive telematics systems, where, for example, it might be desirable to display the settings of ventilation systems over a road map or video programming while it continues to play.
“Automotive telematics systems” refers to the technology of computerized control systems to manage environmental and entertainment systems in automobiles. These systems are also referred to as automobile “infotainment” or “infotronic” systems, or by other similar names. Some of the functionality that such systems may manage includes:                1. supporting entertainment applications such as broadcast radio, video games and playing movies. These entertainment applications can be selectively directed towards different display, speaker and headphone systems in the vehicle;        2. managing vehicle climate control systems;        3. providing Internet access, email and instant messaging services;        4. providing security systems such as anti-theft and automatic dialling;        5. interfacing and synchronizing with portable computing devices such as personal digital assistants (PDAs), laptop computers and notebook computers;        6. displaying electronic road maps, using GPS (global positioning system) technology to select the correct map and to identify the vehicle's actual position on the map. This technology can also be used to advise the user of nearby service stations, restaurants and the other services, provide traffic information, navigation advice and parking availability; and        7. interacting wirelessly with gas station “point of sale” and associated automated banking services; for example, allowing users to purchase gasoline, have their car washed and download movies without having to interact with a live attendent (see for example, “The eGasStation Architecture—Java™ Technology Based Managed Services for Retail Service Stations” by Sun Microsystems, Inc. 2001).This listing is just a small sample of what automobile telematics systems may be designed to support. Additional services will surely be supported by telematics systems over time.Existing Video Systems        
There are two common configurations of video systems in the art.
In one system, a software application draws images, vectors and characters using an API of the operating system which directly manipulates the memory and registers of the graphics card, to affect a display. The software application uses the operating system API, but the software application itself acts as a graphics driver directly manipulating the hardware. In such a system only one software application has access to the graphics card at one time due to hardware contention issues.
In the other system, the software application draws using an API of the operating system which packages and sends out the draw requests. If the packaged draw requests are delivered to a software application that is using an API of the operating system to manipulate the memory and registers of the graphics card to affect a display, those draw requests are rendered to the graphics card and may affect the visible display. In this configuration, the drawing applications and the graphics drivers are separate software processes allowing multiple applications to draw using a single graphics card. The mechanism for delivering the packaged draw requests varies within windowing systems known in the art.
FIG. 1 presents a block diagram of a typical arrangement for a graphics card with layers support 10, as known in the art. When a software application 12 wishes to draw an image, character or vector to the display screen 14, it sends a “draw” request to the API 16 of the operating system 18. The operating system 18 processes the draw request and sends appropriate instructions to the graphics card 20. These instructions are sent via the operating system API 16, and the API 22 of the graphics card 20. Because the operating system 18 has no knowledge of the hardware layers 24 in the graphics card 20, all draw requests are simply going to be passed to the same layer, the primary layer 26. The video image within the primary layer 26 is then passed on to the display screen 14.
If the software application 12 has special knowledge of the API 22 of the graphics card 20 and the rest of the system allows it, then the software application 12 can pass messages directly to and from the graphics card 20 to manipulate the memory and registers of the graphics card 20 (this is the first method described above). Alternatively, if the operating system 18 has a graphics driver with special knowledge of the API 22 of the graphics card 20 and the rest of the system allows it, then the graphics driver in the operating system 18 could manipulate the layers capabilites of the graphics card 20 (this is the second method described above).
APIs to access and control video hardware layers were first provided by graphics card manufacturers who were producing graphics cards with layers support. However, there were at least two major problems with these early APIs:                1. the APIs from different manufactures bore little resemblance to one another, meaning that a software application that needed to access and control the layers feature of a graphics card would work only on one manufacture's graphics card; and        2. windows-type operating systems were completely unaware of the existence of the video hardware layers, so the layers could not be accessed via the operating system API.        
More recently an operating system API became available which presented a consistent but limited interface to hardware layering capabilities, although it was still necessary for a software application to use this specific operating system API to be able to render to the layers supported by the hardware. This limitation made the integration of third party software into a layer-enabled system impossible. In other words, this new operating system API still requires that third party software applications know that the new operating system API has access to the hardware layers, and know how to use it. Typically, third party software applications do not have this knowledge, so this is not a “transparent” solution.
One such API is “DirectFB”—an API which provides generic access to video layers capabilities in a limited fashion. DirectFB is limited to exclusive use of surfaces, with the ability to share the primary display surface to a degree.
Existing operating system APIs that allow a software application to have direct access to a graphics hardware layer, generally preclude that layer from being shared by multiple software applications due to hardware contention issues.
Demand has grown in the automotive, medical instrumentation, consumer, and industrial automation markets for a graphics solution which allows the use of third party software applications, legacy applications, and new software applications that were targeted at more than one project, to be able to leverage the layering capabilities of the chosen graphics hardware.
There is therefore a need for an integrated approach to configure, control, and access (render to) graphical hardware layers which addresses the problems outlined above. The approach chosen must take into account the needs of the target markets:
Automotive: Very size and performance sensitive
Consumer: Very size and performance sensitive
Medical: Very performance sensitive
Industrial Automation: Very performance sensitive
This design must also be provided with consideration for speed of execution, reliability, complexity and scalability.
USPTO Backgrounds
USPTO Backgrounds