Patent Grant
7439981
The present invention relates generally to displaying animated visual information on the screen of a display device, and, more particularly, to efficiently using display resources provided by a computing device.
In all aspects of computing, the level of sophistication in displaying information is rising quickly. Information once delivered as simple text is now presented in visually pleasing graphics. Where once still images sufficed, full motion video, computer-generated or recorded from life, proliferates. As more sources of video information become available, developers are enticed by opportunities for merging multiple video streams. (Note that in the present application, “video” encompasses both moving and static graphics information.) A single display screen may concurrently present the output of several video sources, and those outputs may interact with each other, as when a running text banner overlays a film clip.
Presenting this wealth of visual information, however, comes at a high cost in the consumption of computing resources, a problem exacerbated both by the multiplying number of video sources and by the number of distinct display presentation formats. A video source usually produces video by drawing still frames and presenting them to its host device to be displayed in rapid succession. The computing resources required by some applications, such as an interactive game, to produce just one frame may be significant, the resources required to produce sixty or more such frames every second can be staggering. When multiple video sources are running on the same host device, resource demand is heightened not only because each video source must be given its appropriate share of the resources, but because even more resources may be required by applications or by the host's operating system to smoothly merge the outputs of the sources. In addition, video sources may use different display formats, and the host may have to convert display information into a format compatible with the host's display.
Traditional ways of approaching the problem of expanding demand for display resources fall along a broad spectrum from carefully optimizing the video source to its host's environment to almost totally ignoring the specifics of the host. Some video sources carefully shepherd their use of resources by being optimized for a specific video task. These sources include, for example, interactive games and fixed function hardware devices such as digital versatile disk (DVD) players. Custom hardware often allows a video source to deliver its frames at the optimum time and rate as specified by the host device. Pipelined buffering of future display frames is one example of how this is carried out. Unfortunately, optimization leads to limitations in the specific types of display information that a source can provide: in general, a hardware-optimized DVD player can only produce MPEG2 video based on information read from a DVD. Considering these video sources from the inside, optimization prevents them from flexibly incorporating into their output streams display information from another source, such as a digital camera or an Internet streaming content site. Considering the optimized video sources from the outside, their specific requirements prevent their output from being easily incorporated by another application into a unified display.
At the other end of the optimization spectrum, many applications produce their video output more or less in complete ignorance of the features and limitations of their host device. Traditionally, these applications trust the quality of their output to the assumption that their host will provide “low latency,” that is, that the host will deliver their frames to the display screen within a short time after the frames are received from the application. While low latency can usually be provided by a lightly loaded graphics system, systems struggle as video applications multiply and as demands for intensive display processing increase. In such circumstances, these applications can be horribly wasteful of their host's resources. For example, a given display screen presents frames at a fixed rate (called the “refresh rate”), but these applications are often ignorant of the refresh rate of their host's screen, and so they tend to produce more frames than are necessary. These “extra” frames are never presented to the host's display screen although their production consumes valuable resources. Some applications try to accommodate themselves to the specifics of their host-provided environment by incorporating a timer that roughly tracks the host display's refresh rate. With this, the application tries to produce no extra frames, only drawing one frame each time the timer fires. This approach is not perfect, however, because it is difficult or impossible to synchronize the timer with the actual display refresh rate. Furthermore, timers cannot account for drift if a display refresh takes slightly more or less time than anticipated. Regardless of its cause, a timer imperfection can lead to the production of an extra frame or, worse, a “skipped” frame when a frame has not been fully composed by the time for its display.
As another wasteful consequence of an application's ignorance of its environment, an application may continue to produce frames even though its output is completely occluded on the host's display screen by the output of other applications. Just like the “extra” frames described above, these occluded frames are never seen but consume valuable resources in their production.
What is needed is a way to allow applications to intelligently use display resources of their host device without tying themselves too closely to operational particulars of that host.
The above problems and shortcomings, and others, are addressed by the present invention, which can be understood by referring to the specification, drawings, and claims. According to one aspect of the invention, a graphics arbiter acts as an interface between video sources and a display component of a computing system. (A video source is anything that produces graphics information including, for example, an operating system and a user application.) The graphics arbiter (1) collects information about the display environment and passes that information along to the video sources and (2) accesses the output produced by the sources to efficiently present that output to the display screen component, possibly transforming the output or allowing another application to transform it in the process.
The graphics arbiter provides information about the current display environment so that applications can intelligently use display resources. For example, using its close relationship to the display hardware, the graphics arbiter tells applications the estimated time when the output to the estimated display time, thus improving output quality while decreasing resource waste by avoiding the production of “extra” frames. The graphics arbiter also tells applications the time when a frame was actually displayed. Applications use this information to see whether they are producing frames quickly enough and, if not, may choose to degrade video quality in order to keep up. An application may cooperate with the graphics arbiter to control the application's resource use by directly setting the application's frame production rate. The application blocks its operations until a new frame is called for, the graphics arbiter unblocks the application while it produces the frame, and then the application blocks itself again. Because of its relationship to the host's operating system, the graphics arbiter knows the layout of everything on the display screen. It tells an application when its output is fully or partially occluded so that the application need not expend resources to draw portions of frames that are not visible. By using graphics arbiter-provided display environment information, an application's display output can be optimized to work in a variety of display environments.
The graphics arbiter can itself use display environment information to conserve display resources. The graphics arbiter introduces a level of persistence into the display buffers used to prepare frames for the screen. The arbiter need only update those portions of the display buffers that have changed from the previous frame.
Because the graphics arbiter has access to the output buffers of the applications, it can readily perform transformations on the applications' output before sending the output to the display hardware. For example, the graphics arbiter converts from a display format favored by an application to a format acceptable to the display screen. Output may be “stretched” to match the characteristics of a display screen different from the screen for which the application was designed. Similarly, an application can access and transform the output of other applications before the output is displayed on the host's screen. Three dimensional renderings, lighting effects, and per-pixel alpha blends of multiple video streams are some examples of transformations that may be applied. Because transformations can be performed transparently to the applications, this technique allows flexibility while at the same time allowing the applications to optimize their output to the specifics of a host's display environment.
While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
a through 1e are block diagrams illustrating the operation of memory buffers in typical prior art displays;
a through 2c are flow charts showing successively more sophisticated ways in which prior art display sources deal with display device timing; in the method of
a and 7b are a flowchart of a method usable by a display source when interacting with the graphics arbiter;
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. The following description is based on embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein. Section I presents background information on how video frames are typically produced by applications and then presented to display screens. Section II presents an exemplary computing environment in which the invention may run. Section III describes an intelligent interface (a graphics arbiter) operating between the display sources and the display device. Section IV presents an expanded discussion of a few features enabled by the intelligent interface approach. Section V describes the augmented primary surface. Section VI presents an exemplary interface to the graphics arbiter.
In the description that follows, the invention is described with reference to acts and symbolic representations of operations that are performed by one or more computing devices, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computing device of electrical signals representing data in a structured form. This manipulation transforms the data or maintains them at locations in the memory system of the computing device, which reconfigures or otherwise alters the operation of the device in a manner well understood by those skilled in the art. The data structures where data are maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operations described hereinafter may also be implemented in hardware.
Before proceeding to describe aspects of the present invention, it is useful to review a few basic video display concepts.
At the same time that the display device 102 is reading a frame from the primary presentation surface 104, a display source 106 is writing into the primary presentation surface a frame that it wishes displayed. The display source is anything that produces output for display on the display device: it may be a user application, the operating system of the computing device 100, or a firmware-based routine. For most of the present discussion, no distinction is drawn between these various display sources: they all may be sources of display information and are all treated basically alike.
The system of
b and 1c show a standard way to avoid tearing. The video memory associated with the display device 102 is expanded into a presentation surface set 110. The display device still reads from the primary presentation surface 104 as described above with reference to
The discussion so far focuses on presenting frames for display. Before a frame is presented for display, it must, of course, be composed by a display source 106. With
e makes explicit the point, implicit in the discussion so far, that a display device 102 can simultaneously display information from a multitude of display sources, here illustrated by sources 106a, 106b, and 106c. The display sources may span the spectrum from, e.g., an operating system displaying a static, textual warning message to an interactive video game to a video playback routine. No matter their compositional complexity or their native video formats, all of the display sources eventually deliver their output to the same presentation back buffer 108.
As discussed above, the display device 102 presents frames periodically, at its refresh rate. However, there has been no discussion as to how or whether display sources 106 synchronize their composition of frames with their display device's refresh rate. The flow charts of
A display source 106 operating according to the method of
In this method, there may or may not be an attempt in step 204 to synchronize frame composition with the display device 102's refresh rate. If there is no synchronization attempt, then the display source 106 composes frames as quickly as available resources allow. The display source may be wasting significant resources of its host computing device 100 by composing, say, 1500 frames every second when the display device can only show, say, 72 frames a second. In addition to wasting resources, the lack of display synchronization may prevent synchronization between the video stream and another output stream, such as a desired synchronization of an audio clip with a person's lips moving on the display device. On the other hand, step 204 may be synchronous, throttling composition by only permitting the display source to transfer one frame to the presentation back buffer 108 in each display refresh cycle. In such a case, the display source may waste resources not by drawing extra, unseen frames but by constantly polling the display device to see when it will accept delivery of the next frame.
The simple technique of
The method of
The method of
The computing device 100 of
An intelligent interface is placed between the display sources 106a, 106b, and 106c and the presentation surface 104 of the display device 102. Represented by the graphics arbiter 400 of
While the present application is focused on the inventive features provided by the new graphics arbiter 400, there is no attempt to exclude from the graphics arbiter's functionality any features provided by traditional graphics systems. For example, traditional graphics systems often provide video decoding and video digitization features. The present graphics arbiter 400 may also provide such features in conjunction with its new features.
This intelligent interface approach enables a large number of graphics features. To frame the discussion of these features, this discussion begins by describing exemplary methods of operation usable by the graphics arbiter 400 (in
In the flow chart of
One of the more important aspects of the intelligent interface approach is the use of the display device 102's VSYNC indications as a clock that drives much of the work in the entire graphics system. The effects of this system-wide clock are explored in great detail in the discussions below of the particular features enabled by this approach. In step 604, the graphics arbiter 400 waits for VSYNC before beginning another round of display frame composition.
Using the control flows 502a, 502b, and 502c, the graphics arbiter 400 notifies, in step 606, any interested clients (e.g., display source 106b) of the time at which the composed frame was presented to the display device 102. Because this time comes directly from the graphics arbiter that flips the presentation surface set 110, this time is more accurate than the display source-provided timer in the methods of
When in step 608 the VSYNC indication arrives at the graphics arbiter 400 via information flow 500, the graphics arbiter unblocks any blocked clients so that can perform their part of the work necessary for composing the next frame to be displayed. (Clients may block themselves after they complete the composition of a display frame, as discussed below in reference to
While the graphics arbiter 400 is proceeding through steps 608, 610, and 612, the display sources 106a, 106b, and 106c are composing their next frames and moving them to the ready buffers 116 of their memory surface sets 112a, 112b, and 112c, respectively. However, some display sources may not need to prepare full frames because their display output is partially or completely occluded on the display device 102 by display output from other display sources. In step 612, the graphics arbiter 400, with its system-wide knowledge, creates a list of what will actually be seen on the display device. It provides this information to the display sources so that they need not waste resources in developing information for the occluded portions of their output. The graphics arbiter itself preserves system resources, specifically video memory bandwidth, by using this occlusion information when, beginning the loop again in step 602, it reads only non-occluded information from the ready buffers in preparation for composing the next display frame in the presentation back buffer 108.
In a manner similar to its use of occlusion information to conserve system resources, the graphics arbiter 400 can detect that portions of the display have not changed from one frame to the next. The graphics arbiter compares the currently displayed frame with the information in the ready buffers 116 of the display sources. Then, if the flipping of the presentation surface set 110 is non-destructive, that is, if the display information in the primary presentation surface 104 is retained when that buffer becomes the presentation back buffer 108, then the graphics arbiter need only, in step 602, write those portions of the presentation back buffer that have changed from the previous frame. In the extreme case of nothing changing, the graphics arbiter in step 602 does one of two things. In a first alternative, the graphics arbiter does nothing at all. The presentation surface set is not flipped, and the display device 102 continues to read from the same, unchanged primary presentation surface. In a second alternative, the graphics arbiter does not change the information in the presentation back buffer, but the flip is performed as usual. Note that neither of these alternatives is available in display systems in which flipping is destructive. In this case, the graphics arbiter begins step 602 with an empty presentation back buffer and must entirely fill the presentation back buffer regardless of whether or not anything has changed. Portions of the display may change either because a display source has changed its output or because the occlusion information gathered in step 612 has changed.
At the same time that the graphics arbiter 400 is looping through the method of
In step 702, the display source 106a receives an estimate of when the display device 102 will present its next frame. This is the time sent by the graphics arbiter 400 in step 610 of
If at least some of the display source 106a's output is visible (or if the display source ignores occlusion information), then in step 706 the display source composes a frame, or at least the visible portions of a frame. Various display sources use various techniques to incorporate occlusion information so that they need only draw the visible portions of a frame. For example, three-dimensional (3D) display sources that use Z-buffering to indicate what items in their display lie in front of what other items can manipulate their Z-buffer values in the following manner. They initialize the Z-buffer values of occluded portions of the display as if those portions were items lying behind other items. Then, the Z test will fail for those portions. When these display sources use 3D hardware provided by many graphics arbiters 400 to compose their frames, the hardware runs much faster on the occluded portions because the hardware need not fetch texture values or alpha-blend color buffer values for portions failing the Z test.
The frame composed in step 706 corresponds to the estimated display time received in step 702. Many display sources can render a frame to correspond to any time in a continuous domain of time values, for example by using the estimated display time as an input value to a 3D model of the scene. The 3D model interpolates angles, positions, orientations, colors, and other variables according to the estimated display time. The 3D model renders the scene to create an exact correspondence between the scene's appearance and the estimated display time.
Note that steps 702 and 706 synchronize the display source 106a's frame composition rate with the display device 102's refresh rate. By waiting for the estimated display time in step 702, which is sent by the graphics arbiter 400 in step 610 of
Optionally, the display source 106a receives in step 710 the actual display time of the frame it composed in step 706. This time is based on the flipping of the buffers in the presentation surface set 110 and is sent by the graphics arbiter 400 in its step 606. The display source 106a checks this time in step 712 to see if the frame was presented in a timely fashion. If it was not, then the display source 106a took too long to compose the frame, and the frame was consequently not ready at the estimated display time received in step 702. The display source 106a may have attempted to compose a frame that is too computationally complex for the present display environment, or other display sources may have demanded too many resources of the computing device 100. In any case, in step 714 a procedurally flexible display source takes corrective action in order to keep up with the display refresh rate. The display source 106a, for example, decreases the quality of its composition for a few frames. This ability to intelligently degrade frame quality to keep up with the display refresh rate is an advantage of the system-wide knowledge gathered by the graphics arbiter 400 and reflected in the use of VSYNC as a system-wide clock.
If the display source 106a has not yet completed its display task, then in step 716 of
In some embodiments, the display source 106a blocks its own operation before looping back to step 702 (from either steps 704 or 716). This frees up resources for use by other applications on the computing device 100 and ensures that the display source does not waste resources either in producing extra, never-to-be-seen frames or in polling for permission to transfer the next frame. The graphics arbiter 400 unblocks the display source in step 608 of
A. Format Translation
The graphics arbiter 400's access to the memory surface sets 112a, 112b, and 112c of the display sources 106a, 106b, and 106c allows it to translate from the display format found in the ready buffers 116 into a format compatible with the display device 102. For example, video decoding standards are often based on a YUV color space, while 3D models developed for a computing device 100 generally use an RGB color space. Moreover, some 3D models use physically linear color (the scRGB standard) while others use perceptually linear color (the sRGB standard). As another example, output designed for one display resolution may need to be “stretched” to match the resolution provided by the display device. The graphics arbiter 400 may even need to translate between frame rates, for example accepting frames produced by a video decoder at NTSC's 59.94 Hz native rate and possibly interpolating the frames to produce a smooth presentation on the display device's 72 Hz screen. As yet another example of translation, the above-described mechanisms that enable a display source to render a frame for its anticipated presentation time also enable arbitrarily sophisticated deinterlacing and frame interpolation to be applied to video streams. All of these standards and variations on them may be in use at the same time on one computing device. The graphics arbiter 400 converts them all when it composes the next display frame in the presentation back buffer 108 (step 602 of
B. Application Transformation
In addition to translating between formats, the graphics arbiter 400 can apply graphics transformation effects to the output of a display source 106a, possibly without intervention by the display source. These effects include, for example, lighting, applying a 3D texture map, or a perspective transformation. The display source could provide per-pixel alpha information along with its display frames. The graphics arbiter could use that information to alpha blend output from more than one display source, to, for example, create arbitrarily shaped overlays.
The output produced by a display source 106a and read by the graphics arbiter 400 is discussed above in terms of image data, such as bitmaps and display frames. However, other data formats are possible. The graphics arbiter also accepts as input a set of drawing instructions produced by the display source. The graphics arbiter follows those instructions to draw into the presentation surface set 110. The drawing instruction set can either be fixed and updated at the option of the display source or can be tied to specific presentation times. In processing the drawing instructions, the graphics arbiter need not use an intermediate image buffer to contain the display source's output, but rather uses other resources to incorporate the display source's output into the display output (e.g., texture maps, vertices, instructions, and other input to the graphics hardware).
Unless carefully managed, a display source 106a that produces drawing instructions can adversely affect occlusion. If its output area is not bounded, a higher precedence (output is in front) display source's drawing instructions could direct the graphics arbiter 400 to draw into areas owned by a lower precedence (output is behind) display source, thus causing that area to be occluded. One way to reconcile the flexibility of arbitrary drawing instructions with the requirement that the output from those instructions be bounded is to have the graphics arbiter use a graphics hardware feature called a “scissor rectangle.” The graphics hardware clips its output to the scissor rectangle when it executes a drawing instruction. Often, the scissor rectangle is the same as the bounding rectangle of the output surface, causing the drawing instruction output to be clipped to the output surface. The graphics arbiter can specify a scissor rectangle before executing drawing instructions from the display source. This guarantees that the output generated by those drawing instructions does not stray outside the specified bounding rectangle. The graphics arbiter uses that guarantee to update occlusion information for display sources both in front of and behind the display source that produced the drawing instructions. There are other possible ways of tracking the visibility of display sources that produce drawing instructions, such as using Z-buffer or stencil-buffer information. An occlusion scheme based on visible rectangles is easily extensible to use scissor rectangles when processing drawing instructions.
A display source whose input includes the output from another display source can be said to be “downstream” from the display source upon whose output it depends. For example, a game renders a 3D image of a living room. The living room includes a television screen. The image on the television screen is produced by an “upstream” display source (possibly a television tuner) and is then fed as input to the downstream 3D game display source. The downstream display source incorporates the television image into its rendering of the living room. As the terminology implies, a chain of dependent display sources can be constructed, with one or more upstream display sources generating output for one or more downstream display sources. Output from the final downstream display sources is incorporated into the presentation surface set 110 by the graphics arbiter 400. Because a downstream display source may need some time to process display output from an upstream source, the graphics arbiter may see fit to offset the upstream source's timing information. For example, if the downstream display source needs one frame time to incorporate the upstream display information, then the upstream source can be given an estimated frame display time (see steps 610 in
Occlusion information may be passed up the chain from a downstream display source to its upstream source. Thus, for example, if the downstream display is completely occluded, then the upstream source need not waste any time generating output that would never be seen on the display device 102.
C. An Operational Priority Scheme
Some services under the control of the graphics arbiter 400 are used both by the graphics arbiter 400 itself when it composes the next display frame in the presentation back buffer 108 and by the display sources 106a, 106b, and 106c when they compose their display frames in their memory surface sets 112. Because many of these services are typically provided by graphics hardware that can only perform one task at a time, a priority scheme arbitrates among the conflicting users to ensure that display frames are composed in a timely fashion. Tasks are assigned priorities. Composing the next display frame in the presentation back buffer is of high priority while the work of individual display sources is of normal priority. Normal priority operations proceed only as long as there are no waiting high priority tasks. When the graphics arbiter receives a VSYNC in step 608 of
Pre-emption can be implemented in software by queuing the requests for graphics hardware services. Only high priority requests are submitted until the next display frame is composed in the presentation back buffer 108. Better still, the stream of commands for composing the next frame could be set up and the graphics arbiter 400 prepared in advance to execute it on reception of VSYNC.
A hardware implementation of the priority scheme may be more robust. The graphics hardware can be set up to pre-empt itself when a given event occurs. For example, on receipt of VSYNC, the hardware could pre-empt what it was doing, process the VSYNC (that is, compose the presentation back buffer 108 and flip the presentation surface set 110), and then return to complete whatever it was doing before.
D. Using Scan Line Timing Information
While VSYNC is shown above to be a very useful system-wide clock, it is not the only clock available. Many display devices 102 also indicate when they have completed the display of each horizontal scan line. The graphics arbiter 400 accesses this information via information flow 500 of
The scan line “clock” is used to compose a display frame directly in the primary presentation surface 104 (rather than in the presentation back buffer 108) without causing a display tear. If the bottommost portion of the next display frame that differs from the current frame is above the current scan line position, then changes are safely written directly to the primary presentation surface, provided that the changes are written with low latency. This technique saves some processing time because the presentation surface set 110 is not flipped and may be a reasonable strategy when the graphics arbiter 400 is struggling to compose display frames at the display device 102's refresh rate. A pre-emptible graphics engine has a better chance of completing the write in a timely fashion.
Multiple display surfaces may be used simultaneously to drive the display device 102.
The key to this procedure is the merging in step 1004. Many types of merging are possible, depending upon the requirements of the system. As one example, the display interface driver 900 could compare pixels in the primary presentation surface 104 against a color key. For pixels that match the color key, the corresponding pixel is read from the overlay primary surface 904 and sent to the display device 102. Pixels that do not match the color key are sent unchanged to the display device. This is called “destination color-keyed overlay.” In another form of merging, an alpha value specifies the opacity of each pixel in the primary presentation surface. For pixels with an alpha of 0, display information from the primary presentation surface is used exclusively. For pixels with an alpha of 255, display information from the overlay primary surface 904 is used exclusively. For pixels with an alpha between 0 and 255, the display information from the two surfaces are interpolated to form the value displayed. A third possible merging associates a Z order with each pixel that defines the precedence of the display information.
The exemplary application interface 1100 comprises numerous data structures and functions, the details of which are given below. The boxes shown in
A. Data Type
A.1 HVISUAL
HVISUAL is a handle that refers to a visual. It is passed back by CECreateDeviceVisual, CECreateStaticVisual, and CECreatelSVisual and is passed to all functions that refer to visuals, such as CESetInFront.
typedef DWORD HVISUAL, *PHVISUAL;
B. Data Structures
B.1 CECREATEDEVICEVISUAL
This structure is passed to the CECreateDeviceVisual entry point to create a surface visual which can be rendered with a Direct3D device.
B.2 CECREATESTATICVISUAL
This structure is passed to the CECreateStaticVisual entry point to create a surface visual.
B.3 CECREATEISVISUAL
This structure is passed to the CECreateISVisual entry point to create a surface visual.
B.4 Alpha Information
This structure specifies the constant alpha value to use when incorporating a visual into the desktop, as well as whether to modulate the visual alpha with the per-pixel alpha in the source image of the visual.
C. Function Calls
C.1 Visual Lifetime Management (1102 in
There are several entry points to create different types of visuals: device visuals, static visuals, and Instruction Stream Visuals.
C.1.a CECreateDeviceVisual
CECreateDeviceVisual creates a visual with one or more surfaces and a Direct3D device for rendering into those surfaces. In most cases, this call results in a new Direct3D device being created and associated with this visual. However, it is possible to specify another device visual in which case the newly created visual will share the specified visual's device. As devices cannot be shared across processes, the device to be shared must be owned by the same process as the new visual.
A number of creation flags are used to describe what operations may be required for this visual, e.g., whether the visual will ever be stretched or have a transform applied to it or whether the visual will ever be blended with constant alpha. These flags are not used to force a particular composition operation (blt vs. texturing) as the graphics arbiter 400 selects the appropriate mechanism based on a number of factors. These flags are used to provide feedback to the caller over operations that may not be permitted on a specific surface type. For example, a particular adapter may not be able to stretch certain formats. An error is returned if any of the operations specified are not supported for that surface type. CECreateDeviceVisual does not guarantee that the actual surface memory or device will be created by the time this call returns. The graphics arbiter may choose to create the surface memory and device at some later time.
C.1.b CECreateStaticVisual
CECreateStaticVisual creates a visual with one or more surfaces whose contents are static and are specified at creation time.
C. 1.c CECreatelSVisual
CECreatelSVisual creates an Instruction Stream Visual. The creation call specifies the size of buffer desired to hold drawing instructions.
C.1.d CECreateRefVisual
CECreateRefVisual creates a new visual that references an existing visual and shares the underlying surfaces or Instruction Stream of that visual. The new visual maintains its own set of visual properties (rectangles, transform, alpha, etc.) and has its own z-order in the composition list, but shares underlying image data or drawing instructions.
C.1.e CEDestroyVisual
CEDestroyVisual destroys a visual and releases the resources associated with the visual.
HRESULT CEDestroyVisual(HVISUAL hVisual);
C.2 Visual List Z-Order Management (1104 in
CESetVisualOrder sets the z-order of a visual. This call can perform several related functions including adding or removing a visual from a composition list and moving a visual in the z-order absolutely or relative to another visual.
Flags specified with the call determine which actions to take. The flags are as follows:
A visual can be placed in the output composition space in one of two ways: by a simple screen-aligned rectangle copy (possibly involving a stretch) or by a more complex transform defined by a transformation matrix. A given visual uses only one of these mechanisms at any one time although it can switch between rectangle-based positioning and transform-based positioning.
Which of the two modes of visual positioning is used is decided by the most recently set parameter, e.g., if CESetTransform was called more recently then any of the rectangle-based calls, then the transform is used for positioning the visual. On the other hand, if a rectangle call was used more recently, then the transform is used.
No attempt is made to keep the rectangular positions and the transform in synchronization. They are independent properties. Hence, updating the transform will not result in a different destination rectangle.
C.3.a CESet and Get SrcRect
Set and get the source rectangle of a visual, i.e., the sub-rectangle of the entire visual that is displayed. By default, the source rectangle is the full size of the visual. The source rectangle is ignored for IS Visuals. Modifying the source applies both to rectangle positioning mode and to transform mode.
C.3.b CESet and GetUL
Set and get the upper left corner of a rectangle. If a transform is currently applied, then setting the upper left corner switches from transform mode to rectangle-positioning mode.
C.3.c CESet and GetDestRect
Set and get the destination rectangle of a visual. If a transform is currently applied, then setting the destination rectangle switches from transform mode to rectangle mode. The destination rectangle defines the viewport for IS Visuals.
C.3.d CESet and GetTransform
Set and get the current transform. Setting a transform overrides the specified destination rectangle (if any). If a NULL transform is specified, then the visual reverts to the destination rectangle for positioning the visual in composition space.
C.3.e CESet and GetClipRect
Set and get the screen-aligned clipping rectangle for this visual.
C.4 Visual Blending Control (1108 in
C.4.a CESetColorKey
C.4.b CESet and GetAlphaInfo
Set and get the constant alpha and modulation.
C.5 Visual Presentation Time Feedback (1112 in
Several application scenarios are accommodated by this infrastructure.
Create a frame and pass back information about the frame.
The flags and their meanings are:
Submit the changes in the given visual that was initiated with a CEOpenFrame call. No new frame is opened until CEOpenFrame is called again.
HRESULT CECloseFrame(HVISUAL hvisual);
C.5.c CENextFrame
Atomically submit the frame for the given visual and create a new frame. This is semantically identical to closing the frame on hVisual and opening a new frame. The flags word parameter is identical to that of CEOpenFrame. If CEFRAME_NOWAIT is set, the visual's pending frame is submitted, and the function returns an error if a new frame cannot be acquired immediately. Otherwise, the function is synchronous and will not return until a new frame is available. If NOWAIT is specified and an error is returned, then the application must call CEOpenFrame to start a new frame.
C.5.d CEFRAMEINFO
C.6 Visual Rendering Control (1114 in
CEGetDirect3DDevice retrieves a Direct3D device used to render to this visual. This function only applies to device visuals and fails when called on any other visual type. If the device is shared between multiple visuals, then this function sets the specified visual as the current target of the device. Actual rendering to the device is only possible between calls to CEOpenFrame or CENextFrame and CECloseFrame, although state setting may occur outside this context.
This function increments the reference count of the device.
C.7 Hit Testing (1118 in
C.7.a CESetVisible
Manipulate the visibility count of a visual. Increments (if bVisible is TRUE) or decrements (if bVisible is FALSE) the visibility count. If this count is 0 or below, then the visual is not incorporated into the desktop output. If pCount is non-NULL, then it is used to pass back the new visibility count.
C.7.b CEHitDetect
Take a point in screen space and pass back the handle of the topmost visual corresponding to that point. Visuals with hit-visible counts of 0 or lower are not considered. If no visual is below the given point, then a NULL handle is passed back.
C.7.c CEHitVisible
Increment or decrement the hit-visible count. If this count is 0 or lower, then the visual is not considered by the hit testing algorithm. If non-NULL, the LONG pointed to by pCount will pass back the new hit-visible count of the visual after the increment or decrement.
C.8 Instruction Stream Visual Instructions
These drawing functions are available to Instruction Stream Visuals. They do not perform immediate mode rendering but rather add drawing commands to the IS Visual's command buffer. The hVisual passed to these functions refers to an IS Visual. A new frame for the IS Visual must have been opened by means of CEOpenFrame before attempting to invoke these functions.
Add an instruction to the visual to set the given render state.
Add an instruction to the visual to set the given transformation matrix.
Add an instruction to the visual to set the texture for the given stage.
Add an instruction to the visual to set the properties of the given light.
Add an instruction to the visual to enable or disable the given light.
Add an instruction to the visual to set the current material properties.
In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. For example, the graphics arbiter may simultaneously support multiple display devices, providing timing and occlusion information for each of the devices. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
The present application is a continuation of U.S. patent application 10/074,286, which was filed on Feb. 12, 2002, and which in turn claims the benefit of U.S. Provisional Patent Application 60/278,216, filed on Mar. 23, 2001. That provisional application is hereby incorporated in its entirety by reference. The present application is also related to two other patent applications claiming the benefit of that same provisional application: “Methods and Systems for Preparing Graphics for Display on a Computing Device”, U.S. patent application Ser. No. 10/074,201, filed on Feb. 12, 2002, and “Methods and Systems for Merging Graphics for Display on a Computing Device”, U.S. patent application Ser. No. 10/077.568, filed on Feb. 15, 2002.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4783804 | Juang et al. | Nov 1988 | A |
| 4873630 | Rusterholz et al. | Oct 1989 | A |
| 5193142 | Zhao | Mar 1993 | A |
| 5271088 | Bahler | Dec 1993 | A |
| 5451981 | Drako et al. | Sep 1995 | A |
| 5488694 | McKee et al. | Jan 1996 | A |
| 5583536 | Cahill, III | Dec 1996 | A |
| 5598507 | Kimber et al. | Jan 1997 | A |
| 5668601 | Okada et al. | Sep 1997 | A |
| 5742788 | Priem et al. | Apr 1998 | A |
| 5748866 | Edgar | May 1998 | A |
| 5754681 | Watanabe et al. | May 1998 | A |
| 5778341 | Zeljkovic | Jul 1998 | A |
| 5801717 | Engstrom et al. | Sep 1998 | A |
| 5839105 | Ostendorf et al. | Nov 1998 | A |
| 5844569 | Eisler et al. | Dec 1998 | A |
| 5850232 | Engstrom et al. | Dec 1998 | A |
| 5880707 | Aratani | Mar 1999 | A |
| 5892960 | Seide | Apr 1999 | A |
| 5933806 | Beyerlein et al. | Aug 1999 | A |
| 5956046 | Kehlet et al. | Sep 1999 | A |
| 5960397 | Rahim | Sep 1999 | A |
| 5991442 | Yamada et al. | Nov 1999 | A |
| 6009390 | Gupta et al. | Dec 1999 | A |
| 6040861 | Boroczky et al. | Mar 2000 | A |
| 6070140 | Tran | May 2000 | A |
| 6108628 | Komori et al. | Aug 2000 | A |
| 6151030 | DeLeeuw et al. | Nov 2000 | A |
| 6173258 | Menendez-Pidal et al. | Jan 2001 | B1 |
| 6256607 | Digalakis et al. | Jul 2001 | B1 |
| 6262776 | Griffits | Jul 2001 | B1 |
| 6359631 | DeLeeuw | Mar 2002 | B2 |
| 6377257 | Borrel et al. | Apr 2002 | B1 |
| 6384821 | Borrel et al. | May 2002 | B1 |
| 6473086 | Morein et al. | Oct 2002 | B1 |
| 6476806 | Cunniff et al. | Nov 2002 | B1 |
| 6480902 | Yuang et al. | Nov 2002 | B1 |
| 6526379 | Rigazio et al. | Feb 2003 | B1 |
| 6549948 | Sasaki et al. | Apr 2003 | B1 |
| 6597689 | Chiu et al. | Jul 2003 | B1 |
| 6628297 | Wraae et al. | Sep 2003 | B1 |
| 6664968 | Ono | Dec 2003 | B2 |
| 6753878 | Heirich et al. | Jun 2004 | B1 |
| 6760048 | Bates et al. | Jul 2004 | B1 |
| 6772197 | Lee et al. | Aug 2004 | B1 |
| 6919900 | Wilt | Jul 2005 | B2 |
| 7038690 | Wilt et al. | May 2006 | B2 |
| 7239324 | Wilt et al. | Jul 2007 | B2 |
| 7315307 | Wilt et al. | Jan 2008 | B2 |
| 7315308 | Wilt et al. | Jan 2008 | B2 |
| 20010008577 | Yamada et al. | Jul 2001 | A1 |
| 20020076689 | Farb et al. | Jun 2002 | A1 |
| 20020126987 | Kamiya | Sep 2002 | A1 |
| 20030067467 | Wilt et al. | Apr 2003 | A1 |
| 20030071818 | Wilt et al. | Apr 2003 | A1 |
| 20030084181 | Wilt | May 2003 | A1 |
| 20030225956 | Riley et al. | Dec 2003 | A1 |
| 20040090950 | Lauber et al. | May 2004 | A1 |
| 20040130558 | MacInnis et al. | Jul 2004 | A1 |
| 20040212621 | Wilt et al. | Oct 2004 | A1 |
| 20040217960 | Wilt et al. | Nov 2004 | A1 |
| 20050033893 | Pettey et al. | Feb 2005 | A1 |
| 20060287783 | Walker | Dec 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| 0 736 855 | Oct 1996 | EP |
| 8-163556 | Jun 1996 | JP |
| Number | Date | Country | |
|---|---|---|---|
| 20050083339 A1 | Apr 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60278216 | Mar 2001 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10074286 | Feb 2002 | US |
| Child | 10970261 | US |
