Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20040194020
Kind Code
A1
Beda, Joseph S. ; et al.
September 30, 2004
Markup language and object model for vector graphics
Abstract
An element object model and a vector graphics markup language for using that element object model in a manner that allows program code developers to consistently interface with a scene graph data structure to produce graphics. The vector graphics element object model generally corresponds to shape elements and other elements including image and video elements that correlate with a scene graph object model of the scene graph. Markup may be parsed into data including elements in an element tree that is translated into the objects of a scene graph data structure. Other markup may be translated directly into data and calls that create the scene graph objects. The markup language provides distinct ways to describe an element, including a simple string format or complex property syntax, which may be named, enabling reuse in other locations in the markup.
Inventors:
Beda; Joseph S.
(Seattle, WA)
, Gallo; Kevin T.
(Woodinville, WA
)
, Smith; Adam M.
(Kirkland, WA
)
, Wong; Gilman K.
(Redmond, WA
)
, Subramanian; Sriram
(Kirkland, WA
)
Correspondence Name and Address:
Suite 193 704 -228th Avenue NE
Law Offices of Albert S. Michalik, PLLC
Sammamish
WA
98074
US
Series Code:
693633
Filed:
October 23, 2003
U.S. Current Class:
715/502
U.S. Class at Publication:
715/502
Intern'l Class:
G06F 017/21
Claims
What is claimed is:
1. In a computing environment, a method comprising, receiving a function call via an interface, the function call comprising markup language data; and interpreting the markup language data to cause data in a scene graph to be modified.
2. The method of claim 1 wherein causing data in the scene graph to be modified comprises causing initialization of a new instance of a visual class.
3. The method of claim 2 wherein causing data in the scene graph to be modified comprises invoking code to associate a transform with a visual object in the scene graph.
4. The method of claim 1 wherein causing data in a scene graph data structure to be modified comprises invoking code to place a drawing visual into the scene graph.
5. The method of claim 4 further comprising, causing a drawing context to be returned, the drawing context providing a mechanism for rendering into the drawing visual.
6. The method of claim 2 wherein causing data in the scene graph to be modified comprises invoking code to associate brush data with a visual object in the scene graph.
7. The method of claim 6 wherein the brush data comprises receiving data corresponding to a solid color.
8. The method of claim 6 wherein receiving brush data comprises receiving data corresponding to a linear gradient brush and a stop collection comprising at least one stop.
9. The method of claim 6 wherein receiving brush data comprises receiving data corresponding to a radial gradient brush.
10. The method of claim 6 wherein receiving brush data comprises receiving data corresponding to an image.
11. The method of claim 10 further comprising, receiving markup corresponding to an image effect to apply to the image.
12. The method of claim 1 further comprising, receiving markup corresponding to pen data that defines an outline of a shape.
13. The method of claim 1 wherein the markup corresponds to a shape class comprising at least one of the set containing rectangle, polyline, polygon, path, line and ellipse shapes.
14. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a geometry-related function to represent a rectangle in the scene graph data structure.
15. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a geometry-related function to represent a path in the scene graph data structure.
16. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a geometry-related function to represent a line in the scene graph data structure.
17. The method of claim 1 wherein the markup is related to hit-testing a visual in the scene graph data structure.
18. The method of claim 1 wherein causing data in a scene graph data structure to be modified comprises invoking a function related to transforming coordinates of a visual in the scene graph data structure.
19. The method of claim 1 wherein the markup is related to calculating a bounding box of a visual in the scene graph data structure.
20. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function via a common interface to a visual object in the scene graph data structure.
21. The method of claim 1 further comprising invoking a visual manager to render a tree of at least one visual object to a rendering target.
22. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to place a container object in the scene graph data structure, the container object configured to contain at least one visual object.
23. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to place image data into the scene graph data structure.
24. The method of claim 23 wherein causing data in the scene graph to be modified comprises invoking a function to place an image effect object into the scene graph data structure that is associated with the image data.
25. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to place data corresponding to text into the scene graph data structure.
26. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to provide a drawing context in response to the function call.
27. The method of claim 26 wherein the function call corresponds to a retained visual, and further comprising, calling back to have the drawing context of the retained visual returned to the scene graph data structure.
28. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to place a three-dimensional visual into the scene graph data structure.
29. The method of claim 28 wherein causing data in the scene graph to be modified comprises mapping a two-dimensional surface onto the three dimensional visual.
30. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to place animation data into the scene graph data structure.
31. The method of claim 30 further comprising communicating timeline information corresponding to the animation data to a composition engine.
32. The method of claim 31 wherein the composition engine interpolates graphics data based on the timeline to animate an output corresponding to an object in the scene graph data structure.
33. The method of claim 32 wherein the composition engine is at a low-level with respect to the scene graph.
34. The method of claim 1 wherein causing data in the scene graph to be modified comprises invoking a function to place an object corresponding to audio and/or video data into the scene graph data structure.
35. The method of claim 1 wherein causing data in the scene graph to be modified comprises changing a mutable value of an object in the scene graph data structure.
36. In a computing environment, a system comprising: a markup parser; an interface coupling the markup parser to a source of markup; and a container for visual information of an object model, the markup parser converting markup received at the interface to method calls of objects in the object mode to modify data in the container for visual information.
37. The system of claim 26 wherein the markup is converted to a method call to place a tree of visual objects into the scene graph data structure.
38. The system of claim 37 wherein the markup is converted to at least one method call to arrange a tree of visual objects in the scene graph data structure.
39. The system of claim 37 wherein the markup is converted to a method call to place a visual collection object into the scene graph data structure.
40. The system of claim 26 wherein the markup is converted to a method call to place a visual object into the scene graph data structure.
41. The system of claim 40 wherein the markup is converted to a method call to associate a brush with the visual object.
42. The system of claim 40 wherein the markup is converted to a method call to associate a geometry with the visual object.
43. The system of claim 42 wherein the geometry comprises at least one of a set containing an ellipse geometry, a rectangle geometry, a line geometry and a path geometry.
44. The system of claim 40 wherein the markup is converted to a method call to associate a transform with the visual object.
45. The system of claim 44 wherein the transform comprises a rotate transform for changing a perceived angle of the visual object.
46. The system of claim 44 wherein the transform comprises a scale transform for changing a perceived size of the visual object.
47. The system of claim 44 wherein the transform comprises a translate transform for changing a perceived position of the visual object.
48. The system of claim 44 wherein the transform comprises a skew transform for changing a perceived skew of the visual object.
49. The system of claim 44 wherein the markup provides animation information associated with the transform, and wherein the animation information causes transformation data associated with the transform to change over time thereby animating the transformation of the visual object over time.
50. The system of claim 40 wherein the markup is converted to a method call to associate a color with the visual object.
51. The system of claim 40 wherein the markup is converted to a method call to associate gradient data with the visual object.
52. The system of claim 40 wherein the markup is converted to a method call to associate a tile brush with the visual object.
53. The system of claim 40 wherein the markup is converted to a method call to associate an image with the visual object.
54. The system of claim 40 wherein the markup is converted to a method call to associate a drawing comprising drawing primitives with the visual object.
56. The system of claim 40 wherein the markup is converted to a method call to associate audio and/or video media d with the visual object.
57. The system of claim 40 wherein the markup is converted to a method call to associate an image effect with the visual object.
58. The system of claim 40 wherein the markup is converted to a method call to associate a pen with the visual object, to describe how a shape is outlined.
59. The system of claim 40 wherein the markup is converted to a method call to obtain a drawing context associated with the visual object.
60. The system of claim 40 wherein the markup is converted to a method call to associate hit testing data with the visual object.
61. The system of claim 40 wherein the markup is converted to a method call to associate a rectangle with the visual object.
62. The system of claim 61 wherein the markup includes data describing how a source rectangle should be stretched to fit a destination rectangle.
65. In a computing environment, a system comprising: interface means for receiving function calls comprising markup; parsing means for converting the markup to data corresponding to an object model associated with rendering graphics data; and rendering means for outputting the graphics data.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present invention is a continuation-in-part of U.S. patent application Ser. No. 10/401,717 filed Mar. 27, 2003.
FIELD OF THE INVENTION
[0002] The invention relates generally to computer systems, and more particularly to the processing of graphical and other video information for display on computer systems.
BACKGROUND OF THE INVENTION
[0003] The limits of the traditional immediate mode model of accessing graphics on computer systems are being reached, in part because memory and bus speeds have not kept up with the advancements in main processors and/or graphics processors. In general, the current (e.g., WM_PAINT) model for preparing a frame requires too much data processing to keep up with the hardware refresh rate when complex graphics effects are desired. As a result, when complex graphics effects are attempted with conventional graphics models, instead of completing the changes that result in the perceived visual effects in time for the next frame, the changes may be added over different frames, causing results that are visually and noticeably undesirable.
[0004] A new model for controlling graphics output is described in U.S. patent application Ser. Nos. 10/184,795, 10/184,796, 10/185,775, 10/401,717, 10/402,322 and 10/402,268, assigned to the assignee of the present invention and hereby incorporated by reference. This new model provides a number of significant improvements in graphics processing technology. For example, U.S. Ser. No. 10/184,795 is generally directed towards a multiple-level graphics processing system and method, in which a higher-level component (e.g., of an operating system) performs computationally intensive aspects of building a scene graph, updating animation parameters and traversing the scene graph's data structures, at a relatively low operating rate, in order to pass simplified data structures and/or graphics commands to a low-level component. Because the high-level processing greatly simplifies the data, the low-level component can operate at a faster rate, (relative to the high-level component), such as a rate that corresponds to the frame refresh rate of the graphics subsystem, to process the data into constant output data for the graphics subsystem. When animation is used, instead of having to redraw an entire scene with changes, the low-level processing may interpolate parameter intervals as necessary to obtain instantaneous values that when rendered provide a slightly changed scene for each frame, providing smooth animation.
[0005] U.S. Ser. No. 10/184,796 describes a parameterized scene graph that provides mutable (animated) values and parameterized graph containers such that program code that wants to draw graphics (e.g., an application program or operating system component) can selectively change certain aspects of the scene graph description, while leaving other aspects intact. The program code can also reuse already-built portions of the scene graph, with possibly different parameters. As can be appreciated, the ability to easily change the appearance of displayed items via parameterization and/or the reuse of existing parts of a scene graph provide substantial gains in overall graphics processing efficiency.
[0006] U.S. Ser. No. 10/185,775 generally describes a caching data structure and related mechanisms for storing visual information via objects and data in a scene graph. The data structure is generally associated with mechanisms that intelligently control how the visual information therein is populated and used. For example, unless specifically requested by the application program, most of the information stored in the data structure has no external reference to it, which enables this information to be optimized or otherwise processed. As can be appreciated, this provides efficiency and conservation of resources, e.g., the data in the cache data structure can be processed into a different format that is more compact and/or reduces the need for subsequent, repeated processing, such as a bitmap or other post-processing result.
[0007] While the above improvements provide substantial benefits in graphics processing technology, there still needs to be a way for programs to effectively use this improved graphics model and its other related improvements in a straightforward manner. What is needed is a comprehensive yet straightforward model for programs to take advantage of the many features and graphics processing capabilities provided by the improved graphics model and thereby output complex graphics and audiovisual data in an efficient manner.
SUMMARY OF THE INVENTION
[0008] Briefly, the present invention provides an element object model and a vector graphics markup language for accessing that element object model in a manner that allows program code developers to consistently interface with a scene graph data structure to produce graphics. The vector graphics markup language comprises an interchange format for expressing vector graphics via the element object model. When interpreted, the markup is parsed into data including elements in an element tree that is translated into the objects of a scene graph data structure. At the element tree level, a property system and layout system are provided to provide rich programmability features, including inheritance characteristics and eventing, making it straightforward for scene designers to design possibly complex scenes. In general, the vector graphics elements correspond to shape elements and other elements including image and video elements that correlate with scene graph objects of the scene graph object model. The properties and other resources of the vector graphics elements also correlate with similar properties and resources the scene graph object model.
[0009] The vector graphics system can thus program to an element level, in which each of the drawing shapes is represented as an element at the same level as the rest of the programmable elements in a page/screen, allowing interaction with the layout system, events and properties. The vector graphics system also provides a mechanism for programming to a resource level, by which scene designers can essentially shortcut the element tree and layout system and program directly to the visual API layer that interfaces with the scene graph data structure. This provides a more efficient and lightweight way to output the appropriate object, although losing of some of the programmability of the element level. In one implementation, when a fill of type "visual brush" is programmed, the parser can directly call the API layer with resource level data to create a corresponding visual paint object (which is also a correlation between the element object model and the scene graph object model). In this two-tiered system, element level vector graphics get parsed into created elements, which need later translation to the objects, while resource level vector graphics get parsed and directly stored in an efficient manner. At the same time, the resource level data or the objects created thereby can be referenced by elements and part of the element tree. To this end, elements including visual paint elements may be named. The scene designer thus has the ability to balance efficiency against programmability as needed.
[0010] The element class hierarchy includes a shape class, an image class, a video class and a canvas class. Elements of the shape class include rectangle, polyline, polygon, path, line and ellipse. Each element may include or be associated with fill (property) data, stroke data, clipping data, transform data, filter effect data and mask data. Shapes correspond to geometry (of the scene graph object model) that is drawn with inherited and cascaded presentation properties that are used to construct the pen and the brush needed to draw the shapes. The image class is more specific than a shape and can include more raster graphical data, while the video class allows video (or similar multimedia) to be played within a displayed element. The canvas class may act as a container for shapes, to keep shapes lightweight.
[0011] In one implementation the markup code is interpreted by a parser/translator which generally adds element-level elements to an element tree/property system and attaches data to those elements. The layout system then takes the element tree with the attached presenters and translates the data to objects (via a builder) and calls to a visual API layer that interfaces with the scene graph and creates the scene graph objects.
[0012] The markup language provides distinct ways to describe an element, including a simple string format or a complex object notation (a complex property syntax). For a simple string format, the parser/translator and/or layout system uses a type converter for converting a string to an appropriate visual API object. When the fill attribute is too complex to fit into a single string, complex property syntax, which may be inline in the markup, is used to describe the property set. Because the same rendering model is shared between the element level and the API level, many of the objects are the same, which makes parsing/translation highly efficient and provides other benefits. A resource instance also may be located elsewhere (e.g., in the markup or a file), and referenced by a name. In this manner, a scene designer can reuse an element in the element tree throughout a scene, including elements described by the complex property syntax.
[0013] Other benefits and advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a block diagram representing an exemplary computer system into which the present invention may be incorporated;
[0015] FIG. 2 is a block diagram generally representing a graphics layer architecture into which the present invention may be incorporated;
[0016] FIG. 3 is a representation of a scene graph of visuals and associated components for processing the scene graph such as by traversing the scene graph to provide graphics commands and other data in accordance with an aspect of the present invention;
[0017] FIG. 4 is a representation of a scene graph of validation visuals, drawing visuals and associated Instruction Lists constructed in accordance with an aspect of the present invention;
[0018] FIG. 5 is a representation of a visual class, of an object model, in accordance with an aspect of the present invention;
[0019] FIG. 6 is a representation of various other objects of the object model, in accordance with an aspect of the present invention;
[0020] FIG. 7 is a representation of a transform class hierarchy, in accordance with an aspect of the present invention;
[0021] FIGS. 8 and 9 are representations of transformations of a visual's data in a geometry scale and a non-uniform scale, respectively, in accordance with an aspect of the present invention;
[0022] FIG. 10 is a representation of geometry classes of the object model, in accordance with an aspect of the present invention;
[0023] FIG. 11 is a representation of a PathGeometry structure, in accordance with an aspect of the present invention;
[0024] FIG. 12 is a representation of a scene graph of visuals and Instruction Lists showing example graphics produced by the primitives, in accordance with an aspect of the present invention;
[0025] FIG. 13 is a representation of brush classes of the object model, in accordance with an aspect of the present invention;
[0026] FIGS. 14 and 15 are representations of rendered graphics resulting from data in a linear gradient brush object, in accordance with an aspect of the present invention;
[0027] FIG. 16 is a representation of rendered graphics resulting from data in a radial gradient brush object, in accordance with an aspect of the present invention;
[0028] FIG. 17 is a representation of a rendered nine grid brush object in accordance with an aspect of the present invention.
[0029] FIG. 18 is a representation of rendered graphics resulting from having various stretch values, in accordance with an aspect of the present invention;
[0030] FIG. 19 is a representation of rendered graphics resulting from having various tile values, in accordance with an aspect of the present invention;
[0031] FIG. 20 is a representation of a grid and transformed grid, resulting from data in a visual brush object, in accordance with an aspect of the present invention;
[0032] FIG. 21 is a representation of the grid and transformed grid, with rendered graphics therein drawn from a visual, in accordance with an aspect of the present invention;
[0033] FIG. 22 is a representation of element classes of the element object model, in accordance with an aspect of the present invention;
[0034] FIG. 23 is a representation of components for interpreting markup language code to interface with the visual API layer, in accordance with an aspect of the present invention; and
[0035] FIG. 24 is a representation of clipping via a geometry path in accordance with an aspect of the present invention.
DETAILED DESCRIPTION
[0036] Exemplary Operating Environment
[0037] FIG. 1 illustrates an example of a suitable computing system environment 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.
[0038] The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
[0039] The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
[0040] With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. Components of the computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Accelerated Graphics Port (AGP) bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
[0041] The computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 110. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
[0042] The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131
and random access memory (RAM) 132. A basic input/output system 133
(BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1 illustrates operating system 134, application programs 135, other program modules 136 and program data 137.
[0043] The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
[0044] The drives and their associated computer storage media, discussed above and illustrated in FIG. 1, provide storage of computer-readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146 and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers herein to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 110 through input devices such as a tablet (electronic digitizer) 164, a microphone 163, a keyboard 162 and pointing device 161, commonly referred to as mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160
that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. The monitor 191 may also be integrated with a touch-screen panel 193 or the like that can input digitized input such as handwriting into the computer system 110 via an interface, such as a touch-screen interface 192. Note that the monitor and/or touch screen panel can be physically coupled to a housing in which the computing device 110 is incorporated, such as in a tablet-type personal computer, wherein the touch screen panel 193 essentially serves as the tablet 164. In addition, computers such as the computing device 110 may also include other peripheral output devices such as speakers 195 and printer 196, which may be connected through an output peripheral interface 194 or the like.
[0045] The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181
has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
[0046] When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
[0047] Graphics Architecture
[0048] One aspect of the present invention is generally directed to allowing program code, such as an application or operating system component, to communicate drawing instructions and other information (e.g., image bitmaps) to graphics components in order to render graphical output on the system display. To this end, the present invention provides a markup language along with a set of shape elements and other elements, a grouping and compositing system, and integration with a general property system in an object model to enable programs to populate a scene graph with data structures, drawing primitives (commands), and other graphics-related data. When processed, the scene graph results in graphics being displayed on the screen.
[0049] FIG. 2 represents a general, layered architecture 200 into which the present invention may be implemented. As represented in FIG. 2, program code 202 (e.g., an application program or operating system component or the like) may be developed to output graphics data in one or more various ways, including via imaging 204, via vector graphic elements 206, and/or via function/method calls placed directly to a visual application programming interface (API) layer 212. Direct interaction with the API layer is further described in the aforementioned copending patent application entitled "Visual and Scene Graph Interfaces."
[0050] In general, imaging 204 provides the program code 202 with a mechanism for loading, editing and saving images, e.g., bitmaps. These images may be used by other parts of the system, and there is also a way to use the primitive drawing code to draw to an image directly.
[0051] In accordance with an aspect of the present invention, vector graphics elements 206 provide another way to draw graphics, consistent with the rest of the object model (as described below). Vector graphic elements 206 may be created via a markup language, which an element/property system 208 and layout system 210 processes to make appropriate calls to the visual API layer 212. As described below, in general the vector graphic elements 206 are parsed into objects of the object model from which a scene graph is drawn, which may be provided to the scene graph via an element level via the element/property system 208
and layout system 210, or may be provided in a more efficient manner at a resource level, as also described below.
[0052] In one implementation, the graphics layer architecture 200 includes a high-level composition and animation engine 214, which includes or is otherwise associated with a caching data structure 216. The caching data structure 216 contains a scene graph comprising hierarchically-arranged objects that are managed according to a defined object model, as described below. In general, the visual API layer 212 provides the program code 202 (and the layout system 210) with an interface to the caching data structure 216, including the ability to create objects, open and close objects to provide data to them, and so forth. In other words, the high-level composition and animation engine 214 exposes a unified media API layer 212 by which developers may express intentions about graphics and media to display graphics information, and provide an underlying platform with enough information such that the platform can optimize the use of the hardware for the program code. For example, the underlying platform will be responsible for caching, resource negotiation and media integration.
[0053] In one implementation, the high-level composition and animation engine 214 passes an instruction stream and possibly other data (e.g., pointers to bitmaps) to a fast, low-level compositing and animation engine 218. As used herein, the terms "high-level" and "low-level" are similar to those used in other computing scenarios, wherein in general, the lower a software component is relative to higher components, the closer that component is to the hardware. Thus, for example, graphics information sent from the high-level composition and animation engine 214
may be received at the low-level compositing and animation engine 218, where the information is used to send graphics data to the graphics subsystem including the hardware 222.
[0054] The high-level composition and animation engine 214 in conjunction with the program code 202 builds a scene graph to represent a graphics scene provided by the program code 202. For example, each item to be drawn may be loaded with drawing instructions, which the system can cache in the scene graph data structure 216. As will be described below, there are a number of various ways to specify this data structure 216, and what is drawn. Further, the high-level composition and animation engine 214
integrates with timing and animation systems 220 to provide declarative (or other) animation control (e.g., animation intervals) and timing control. Note that the animation system allows animate values to be passed essentially anywhere in the system, including, for example, at the element property level 208, inside of the visual API layer 212, and in any of the other resources. The timing system is exposed at the element and visual levels.
[0055] The low-level compositing and animation engine 218 manages the composing, animating and rendering of the scene, which is then provided to the graphics subsystem 222. The low-level engine 218 composes the renderings for the scenes of multiple applications, and with rendering components, implements the actual rendering of graphics to the screen. Note, however, that at times it may be necessary and/or advantageous for some of the rendering to happen at higher levels. For example, while the lower layers service requests from multiple applications, the higher layers are instantiated on a per-application basis, whereby is possible via the imaging mechanisms 204 to perform time-consuming or application-specific rendering at higher levels, and pass references to a bitmap to the lower layers.
[0056] Scene Graph Object Model
[0057] As described below, the rendering model is shared by the higher-level, control-based vector graphics elements 206, and the lower-level objects created by the visual API layer 212 used in the scene graph data structure 216. This provides a significant amount of correlation between the higher-level elements of the present invention, and the lower-level objects. The following describes one implementation of the scene graph object model.
[0058] The present invention offers several layers of access to graphics and rendering services. At a top layer, Vector Graphics) provides a number of advantages common to XML-based graphics markup, including that it is straightforward to use with the object model of the present invention, it is readily reusable, and it is generally familiar to users of similar systems. Objects are available as markup elements, with properties exposed either as attributes on those elements or as complex properties.
[0059] The present invention renders graphics content through the use of Visual objects. This underlying Visual layer is available in several ways. Programmers can access visuals directly in code; they can program using the object model; and, in accordance with an aspect of the present invention, they can use XML-based markup.
[0060] Predefined vector shapes are available in Vector Graphics, like the Polygon and Path elements, and are contained within a layout element, such as Canvas, Dock Panel, and Flow Panel. The Canvas element provides a means for absolutely positioning elements within a parent space. For the Canvas and its child shapes, the default unit of measurement for screen coordinates is the device independent pixel. DockPanel and FlowPanel provide a number of size and alignment properties, as well as control over borders.
[0061] Vector Graphics provides a number of defined vector graphics shapes that will be familiar to users of SVG. These elements inherit from the Shape class, and include Ellipse, Line, Path, Polygon, Polyline, and Rectangle. These elements inherit a number of common attributes from Shape, including Stroke and StrokeThickness, Fill, and data attributes to specify coordinates and vertices. Developers can also skew, rotate, translate, and scale shapes by applying transformations.
[0062] The Line element provides a convenient example. The following example specifies coordinates for the start and end points, a stroke color and width, and rounded capping on the ends of the line.
1
<Canvas ID="root" xmlns="http://schemas.mic- rosoft.com/2003/xaml" Background="White"> <Line Stroke="#000000" StrokeThickness="10" StrokeStartLineCap="2" StrokeEndLineCap="2" X1="200" Y1="10" X2="50" Y2="300"/> </Canvas>
[0063] An Ellipse is created by defining the shape's center with the CenterX and CenterY properties. Instead of specifying foci, the bounds of the ellipse are set by setting the RadiusX and RadiusY properties. To draw a circle in Vector Graphics, the developer can specify an ellipse whose RadiusX and RadiusY values are equal.
2
<Ellipse Fill="yellow" CenterX="3in" CenterY="2.2in" RadiusX="1in" RadiusY="2in" FillOpacity="0.3" StrokeWidth="4px" Stroke="blue"/>
[0064] The Path object provides the means to draw curves and complex shapes, whether open or closed. Path exposes the properties generally available on objects that inherit from the Shape class, but also enables developers to specify more complex parameters to describe curves. Developers can use paths in markup in various ways, including to specify path data using a special syntax in the Data, or specify individual path segments using the PathGeometry and PathGeometry objects.
[0065] The coordinate pairs and inline parameters provided for the Data attribute can specify line segments, Bzier curves, and a variety of other path specifications. The following example shows a Path element that defines two subpaths.
3
<Canvas ID="root" xmlns="http://schemas.mic- rosoft.com/2003/xaml" Background="White"> <Path Data="M 100,200 C 100,25 400,350 400,175 H 280" Stroke="DarkGoldenRod" StrokeThickness="3"/>s </Canvas
[0066] The Data attribute string begins with the "moveto" command, indicated by M, which establishes a start point for the path in the coordinate system of the Canvas. Path data parameters are case-sensitive. The capital M indicates an absolute location for the new current point. A lowercase m would indicate relative coordinates. The first subpath is a cubic Bzier curve beginning at (100,200) and ending at (400,175), drawn using the two control points (100,25) and (400,350). This subpath is indicated by the C command in the Data attribute string. Again, the capital C indicates an absolute path; the lowercase c would indicate a relative path.
[0067] The second subpath begins with an absolute horizontal "lineto" command H, which specifies a line drawn from the preceding subpath's endpoint (400,175) to a new endpoint (280,175). Because it is a horizontal "lineto" command, the value specified is an x-axis coordinate.
[0068] It is also possible to use a more verbose syntax to specify path data in markup, which might have the advantage of allowing the developer to specify complex properties and make the markup more readable. In this case, the PathGeometry object may be used to create complex shapes, such as arcs and curves. PathGeometry objects are comprised of one or more PathFigure objects; each PathFigure represents a different "figure" or shape. Each PathFigure is itself comprised of one or more PathSegment objects, each representing a connected portion of the figure or shape. Segment types include LineSegment, BezierSegment, and ArcSegment.
[0069] The following code specifies path data by using the PathGeometry and a PathFigure; several segments are added to the PathFigure to form a shape. In this case, segments have been added using the PathFigure object's Segments property. This markup creates four Bzier curves. Note that the first segment of a PathFigure is a StartSegment:
4
<Canvas ID="root" Background="White" xmlns="http://schemas.microsoft.com/2003/xaml"> <Path ID="myPath" Fill="Blue" Stroke="Black" StrokeThickness="5"> <Path.Data> <GeometryCollection> <PathGeometry> <PathGeometry.Figures> <PathFigureCollection> <PathFigure> <PathFigure.Segments> <PathSegmentCollection> <StartSegment Point= "400,100"/> <BezierSegment Point1= "400,100" Point2="400,200" Point3="200,300"/> <BezierSegment Point1= "400,300" Point2="400,100" Point3="200,50"/> <BezierSegment Point1= "0,100" Point2="0,200" Point3="200,300"/> <BezierSegment Point1= "0,300" Point2="0,100" Point3="200,50"/> </PathSegmentCollecti- on> </PathFigure.Segments> </PathFigure> </PathFigureCollection> </PathGeometry.Figures> </PathGeometry> </GeometryCollection> </Path.Data> </Path> </Canvas>
[0070] The Vector Graphics shapes expose various attributes of the Brush object to specify the color of their Stroke and Fill. The following example specifies these attributes on Canvas and Ellipse elements. Note that valid input for color properties can be either a keyword or hexadecimal color value.
5
<Canvas ID="root" xmlns="http://schemas.mic- rosoft.com/2003/xaml" Background="LightGray"> <Ellipse Fill="#FFFFFF00" CenterX="100" CenterY="200" RadiusX="75" RadiusY="75" StrokeThickness="5" Stroke="#FF0000FF"/> </Canvas>
[0071] Alternatively, a developer can use complex property syntax and the SolidColorBrush class to specify colors. Specifying properties using more complex syntax becomes necessary when reusing graphics markup with property sheets, or to animate shape properties like color.
6
<Canvas ID="root" xmlns="http://schemas.mic- rosoft.com/2003/xaml" Background="LightGray">
[0072] This irregular polyline shape uses pre-defined color values for the Stroke and Fill properties. The FillOpacity property affects the fill color in this case by makingit slightly transparent (opacity of 0.8) so that it blends with any underlying color:
7
<Polyline Points="300,200 400,125 400,275
300,200" Stroke="Purple" StrokeThickness="2.3"> <Polyline.Fill> <SolidColorBrush Color="Blue" Opacity="0.4"/> </Polyline.Fill> </Polyline></Canvas>
[0073] Just as when specifying solid color fills and backgrounds for shapes, gradients may be specified. The following example sets a horizontal gradient as the Fill property of a Rectangle, with Blue as the start color and Red as the end color.
8
<Rectangle Fill="HorizontalGradient Blue Red" RectangleLeft="120" RectangleTop="120" RectangleWidth="100" RectangleHeight="100"> </Rectangle>
[0074] A developer can also specify gradients with complex property notation. This notation provides a greater degree of specificity in rendering the gradient and exposes additional properties. To animate a shape's fill with a gradient, for example, complex notation would be used. The following example uses the RadialGradientBrush object to set a gradient on a Rectangle. The RadialGradientBrush object provides access to the gradient's properties, like its radius and any transforms or animations that might be set on it; these properties are inherited from GradientBrush. The GradientStopCollection collection enables the developer to specify multiple gradient stops and indicate their Offset (the location of the stop in the gradient):
9
<Rectangle RectangleLeft="10" RectangleTop="250" RectangleWidth="300" RectangleHeight="200"> <Rectangle.Fill> <RadialGradientBrush Focus="0.5,0.5"> <RadialGradientBrush.GradientStops> <GradientStopCollection> <GradientStop Color="red" Offset="0"/> <GradientStop Color="yellow" Offset="1"/> <GradientStop Color="blue" Offset="0.5"/> </GradientStopCollection> </RadialGradientBrush.Gradient- Stops> </RadialGradientBrush> </Rectangle.Fill> </Rectangle>
[0075] The present invention provides standard transformations for vector-drawn shapes. A developer can skew shapes, rotate them, change their scale, and translate (reposition) them either as static graphics or in animations. To use the Transform objects in markup, they need to be specified as children of the TransformDecorator.
[0076] The ScaleTransform transformation is the most straightforward of the available transformations, and is used by simply specifying a factor by which the element should be resized. The following example resizes a Polygon element by 150 percent along the y-axis of the coordinate system of the parent Canvas:
10
<Canvas ID="root" xmlns="http://schemas.mi- crosoft.com/2003/xaml"> <TransformDecorator AffectsLayout="false"> <TransformDecorator.Transform> <ScaleTransform ScaleX="1" ScaleY="1.5"/> </TransformDecorator.Transform> <Polygon ID="star3" Stroke="red" StrokeThickness="2.0" Points="176.5,50
189.2,155.003 286.485,113.5 201.9,177
286.485,240.5
189.2,198.997 176.5,304 163.8,198.997 66.5148,240.5
151.1,177
66.5148,113.5
163.8,155.003" /> </TransformDecorator> </Canvas>
[0077] Note that if specifying further transformations in the same TransformDecorator object, the need to be enclosed in a TransformCollection. Also, the order in which each transformation is parsed and applied makes a difference in the final effect. For example, rotating an element before translating it to different screen coordinates may make a difference.
[0078] The following example shows a rotation and a translation applied to two polyline elements:
11
<!-- Rotate, then translate --> <TransformDecorator AffectsLayout="false"> <TransformDecorator.Transform> <TransformCollection> <RotateTransform Angle="45" /> <TranslateTransform X="100" Y="100" /> </TransformCollection> </TransformDecorator.Transform>- ; <Polyline ID="box4" Stroke="Green" StrokeThickness="5" Points="0,0 10,10 10,50 50,50 50,10
10,10"> </Polyline> </TransformDecorator> <!-- Translate, then rotate --> <TransformDecorator AffectsLayout="false"> <TransformDecorator.Transform> <TransformCollection> <TranslateTransform X="200" Y="200" /> <RotateTransform Angle="15" /> </TransformCollection> </TransformDecorator.Transform> <Polyline ID="box5" Stroke="Cyan" StrokeThickness="5" Points="0,0 10,10 10,50 50,50 50,10 10,10"> </Polyline> </TransformDecorator>
[0079] Note that these two transformations do not yield the same final screen position for their respective shapes. When using the rotation transformation, the transformation rotates the entire coordinate system for a particular element. Depending on an element's position with respect to the origin, the effect of the rotation might not be to rotate it "in place." For example, for an element positioned 200 units from zero along the x-axis, for instance, a rotation of 30 degrees has the effect of swinging the element 30 degrees along a circle with radius 200, drawn around the origin. For this reason, it is more straightforward when dealing with a Transform to translate the element to the origin, apply a rotation, skew, or scale transformation, and then translate the element back to its eventual location.
[0080] A particular syntax may be used to specify a rotation around a particular point, independent of other translations in the transform settings. In effect, this syntax specifies a translation to a new origin, a rotation, and a translation back to the former origin. To specify a rotation of r degrees around a point (cx,cy), use the following syntax:
[0081] transform="rotate(rx [cx,cy])"
[0082] The skew transformation enables the developer to distort a shape along one or both axes. The SkewTransform class provides AngleX and AngleY properties that specify a proportional offset along either axis.
12
<Canvas ID="root" xmlns="http://schemas.mi- crosoft.com/2003/xaml"> <!-- Skewed in X --> <TransformDecorator AffectsLayout="false"> <TransformDecorator.Transform> <TransformCollection> <SkewTransform AngleX="30" /> <TranslateTransform X="0" Y="100" /> </TransformCollection> </TransformDecorator.Transform>- ; <Rectangle RectangleTop="30" RectangleLeft="30" RectangleWidth="80" RectangleHeight="50" Stroke="Red" StrokeThickness="5" /> </TransformDecorator> <!-- Skewed in Y --> <TransformDecorator AffectsLayout="false"> <TransformDecorator.Transform> <TransformCollection> <SkewTransform AngleY="10" /> <TranslateTransform X="0" Y="200" /> </TransformCollection> </TransformDecorator.Transform>- ; <Rectangle RectangleTop="30" RectangleLeft="30" RectangleWidth="80" RectangleHeight="50" Stroke="Blue" StrokeThickness="5" > </Rectangle> </TransformDecorator>
[0083] As with the other transformations, the effect of applying skew transforms is to skew the coordinate system, not merely the shape. Thus, the coordinate system is skewed from the origin, wherever that origin is set. If skewing transformations on shapes that are some distance from the origin, the "empty space" also reflects the skew, affecting element positioning. For the same reason, the order in which developers apply positioning transformations affects a rendered skew or rotation.
[0084] A brush is used anytime color is added to a shape or control. The present invention provides markup that enables the developer's application to paint a user interface (UI) element with anything from a simple solid color to a complex set of patterns and images.
[0085] Brushes can color the interior and edges of shapes drawn on a canvas. They can also be used to change the appearance of any elements that make up the UI. The following are some attributes of the Brush type and can accept any of the brushes:
[0086] Control.Background
[0087] Control.BorderBrush
[0088] Column.Background
[0089] Text.Foreground
[0090] Shape.Fill
[0091] Shape.Stroke
[0092] There are two main types of brushes, namely vector and bitmap brushes. Vector-based brushes include SolidColorBrush, LinearGradientBrush, RadialGradientBrush, and DrawingBrush (although a DrawingBrush can contain shapes filled with bitmaps). Bitmap-based brushes include ImageBrush and NineGridBrush. In general, bitmaps lose quality when stretched or scaled to fill an area; vectors do not. Therefore, vector-based brushes should be used whenever possible.
[0093] A basic type of fill is a SolidColorBrush, which fills an area with a solid color. There are several ways to specify a solid color. Well-known colors can be selected by name. For example, the Fill attribute of a shape can be set to "Red." A color can be chosen from the 32-bit color palette by specifying the amounts of red, green, and blue to combine into a single solid color. The format for specifying a color from the 32-bit palette is "#RRGGBB", where RR is a two digit hexadecimal number specifying the relative amount of red, GG specifies the amount of green, and BB specifies the amount of blue. Additionally, the color can be specified as "#AARRGGBB" where AA specifies the alpha channel, or transparency, of the color. Other color schemes are feasible.
[0094] In the following example, the Fill of an Ellipse element is set using one of the predefined color names.
13
<Canvas xmlns="http://schemas.microsoft.co- m/2003/xaml"> <Ellipse Fill="Red" CenterX="80" CenterY="80" RadiusX="50" RadiusY="50" /> </Canvas>
[0095] While the alpha channel can be specified directly in any solid color brush, it can also be specified with the brush's Opacity property. The opacity of an entire element and its child elements may be specified using the UIElement.Opacity property. Each of these values is specified as a Double between zero and one. A value of one is fully opaque and a value of zero is fully transparent. The various methods of describing opacity are cumulative. That is, if the alpha channel is 0.times.7F (50
percent opacity) and the UIElement.Opacity property is 0.5 (50 percent opacity), the element is painted with 25 percent opacity.
[0096] A gradient brush is a fill that changes from one color to another along an axis. There are two types of gradients supported in Vector Graphics (Vector Graphics): linear and radial gradients.
[0097] The basic building block of a gradient brush is the gradient stop. A gradient stop specifies a color at a relative offset along the gradient axis. The color of the points between gradient stops is linearly interpolated as a combination of the color specified by the two bounding gradient stops. The offset is a Double that ranges from zero to one. Examples of Gradients are set forth below.
[0098] One way to have a Gradient brush is by specifying gradient stops explicitly. The following is an example:
14
<Button.Background> <LinearGradientBrush> <LinearGradientBrush.GradientStops- > <GradientStopCollection> <GradientStop Color="Red" Offset="0" /> <GradientStop Color="Blue" Offset="0.25"/> <GradientStop Color="Orange" Offset="0.75"/> <GradientStop Color="Yellow" Offset="1"/> </Gradient StopCollection> </LinearGradientBrush.GradientStops> </LinearGradientBrush> </Button.Background>
[0099] In the following example, a LinearGradientBrush is used to fill the Background of a Button with a linear gradient that has four gradient stops.
15
<Button.Background> <LinearGradientBrush> <LinearGradientBrush.GradientStops- > <GradientStopCollection> <GradientStop Color="Red" Offset="0" /> <GradientStop Color="Blue" Offset="0.25"/> <GradientStop Color="Orange" Offset="0.75"/> <GradientStop Color="Yellow" Offset="1"/> </GradientStopCollection> </LinearGradientBrush.GradientStops> </LinearGradientBrush> </Button.Background>
[0100] A RadialGradientBrush is used to fill an area with a radial gradient. A radial gradient is similar to a linear gradient, but the gradient axis is from the interior of an ellipse to the exterior. A circle filled with a radial gradient might have a yellow center and a green outline, with interpolated colors in between. The following image shows a rectangle filled with a radial gradient that goes from white to grey. The outside circle represents the gradient circle while the red dot denotes the focal point. This gradient has its SpreadMethod set to Pad.
[0101] In the following example, the Fill property of a Rectangle element is set using a RadialGradientBrush. The radial gradient has a Focus point of (0.5,0.5).
16
<Rectangle.Fill> <RadialGradientBrush Focus="0.5,0.5"> <RadialGradientBrush.GradientStops> <GradientStopCollect- ion> <GradientStop Color="red" Offset="0"/> <GradientStop Color="yellow" Offset="1"/> <GradientStop Color="blue" Offset="0.5"/> </GradientStopCollection> </RadialGradientBrush.GradientStops> </RadialGradientBrush> </Rectangle.Fill>
[0102] When creating a gradient with only two colors, keywords can be used for the stroke, fill, and background properties to simplify the notation. The following sample shows how to create a rectangle filled with a horizontal gradient, a type of linear gradient, that changes from blue to red.
17
<Rectangle Fill="HorizontalGradient Blue Red" RectangleLeft="120" RectangleTop="120" RectangleWidth="100" RectangleHeight="100" />
[0103] The abbreviated syntax for creating horizontal, vertical, and radial gradients is the following:
[0104] GradientType StartColor EndColor, where GradientType is VerticalGradient, HorizontalGradient, or RadialGradient.
[0105] StartColor and EndColor may be predefined color names (such as Blue) or hexadecimal values.
[0106] A vertical gradient is a linear gradient whose start and end points form a vertical line; similarly, a horizontal gradient is a linear gradient whose start and end points form a horizontal line. Developers can explicitly describe their own two-color linear gradients using the following syntax: LinearGradient StartPoint EndPoint StartColor EndColor, where StartPoint and EndPoint are the starting and ending coordinates, with each coordinate expressed as a pair of x and y values from zero to one, such as 0.1,0.1 and 0.5,0.5. These values indicate the relative position of the start or end point; an end point of 0.5,0.5 would be located 50 percent to the right of the fill area and 50 percent of the way from the top of the area-placing the point in the middle of the shape.
[0107] In the following example, the Fill property of a Rectangle element is set by explicitly using a linear gradient.
18
<Rectangle Fill="LinearGradient 0.1,0.1
0.5,0.5 Blue Green" RectangleLeft="220" RectangleTop="220" RectangleWidth="100" RectangleHeight="100" />
[0108] The following example demonstrates how to fill an area with a two-color radial gradient using abbreviated syntax:
19
<Rectangle Fill="RadialGradient Blue Red" RectangleLeft="320" RectangleTop="320" RectangleWidth="100" RectangleHeight="100" />
[0109] In addition to the Fill attribute, gradients can also be used to fill the outline of an object, such as the Stroke of Shape elements.
[0110] A drawing brush makes it possible to fill a shape or control with combinations of other shapes and brushes. Shapes inside of a DrawingBrush, unlike normal Shape elements, are not elements in the element tree. Instead, they are parsed and rendered directly by the media layer. This can result in significantly improved performance in cases where the part of the user interface is composed of many shapes.
[0111] A drawing brush is a type of TileBrush. The section provides information about additional features the developer can use to control how a drawing brush fills its output area.
[0112] An ImageBrush fills an area with a bitmap image. The following sample shows how to use an ImageBrush to render an image as the background of a Canvas.
20
<Canvas Height="400" Width="600" xmlns="http://schemas.microsoft.com/2003/xaml" > <Canvas.Background> <ImageBrush Stretch="Uniform" HorizontalAlignment="Left" VerticalAlignment="Top" ImageSource="gecko.jpg" /> </Canvas.Background> </Canvas>
[0113] An image brush is a type of Tile Brush. The section provides information about additional features developers can use to control how an image fills its output area.
[0114] Both DrawingBrush and ImageBrush are types of tile brushes (they derive from the TileBrush class). Therefore, they have a common set of features that enable developers to control with great detail how an area is filled. For example, instead of just filling an area with a single stretched image, developers can fill an area with a series of image tiles that create a pattern.
[0115] A tile brush describes one or more tiles filled with content. An ImageBrush is a tile brush that fills its tiles with a bitmap image. A DrawingBrush is a tile brush that fills its tiles with a drawing.
[0116] Tile brushes provide the developer with two levels of control; developers can control how the brush's content fills its tiles, and the developer can control how the brush's tiles fill an area. By default, the tile brush fills the output area with a single tile, and the brush's content is stretched to fill that tile. Some of the properties that enable the developer to override this default behavior are the Stretch, ViewPort, and ViewBox properties. The Stretch property (also described below with reference to FIG. 18) defines how the brush's content fills its tiles. The ViewPort defines the size and position of a brush's tiles, and the ViewBox property determines the size and position of the brush's content.
[0117] The Stretch property controls how a tile brush's content is stretched to fill its tiles. The Stretch property accepts the following values, defined by the Stretch enumeration:
[0118] None: The brush's content is not stretched to fill the tile.
[0119] Fill: The brush's content is scaled to fit the tile. Because the content's height and width are scaled independently, the original aspect ratio of the content might not be preserved. That is, the brush's content might be warped in order to completely fill the output tile.
[0120] Uniform: The brush's content is scaled so that it fits completely within the tile. The content's aspect ratio is preserved.
[0121] UniformToFill: The brush's content is scaled so that it completely fills the output area while preserving the content's original aspect ratio.
[0122] The HorizontalAlignment and VerticalAlignment properties determine how a tile brush's content is aligned within its tiles. The HorizontalAlignment property accepts the following values, defined by the HorizontalAlignment enumeration: Left, Center, and Right. The VerticalAlignment property accepts the following values, defined by the VerticalAlignment enumeration: Top, Center, and Bottom.
[0123] The ViewPort property determines the size and position of a brush's tiles. The ViewPortUnits property determines whether the ViewPort is specified using absolute or relative coordinates. If the coordinates are relative, they are relative to the size of the output area. The point (0,0) represents the top left corner of the output area, and (1,1) represents the bottom right corner of the output area. To specify that the ViewPort property uses absolute coordinates, set the ViewPortUnits property to Absolute.
[0124] In the following example, an image is used to create a tile that has a width and height of 100, and with its top left corner at (0,0).
21
<Rectangle.Fill> <ImageBrush ViewPort="0,0 100,100" ViewPortUnits="Absolute" ImageSource="help.gif" TileMode="Tile"/> </Rectangle.Fill>
[0125] The size and position of the brush's content can be specified using the ViewBox property. When a tile brush's tile doesn't completely fill the output area, its TileMode property specifies how the remaining output area is filled. The TileMode property accepts the following values, defined by the TileMode enumeration:
[0126] None: Only the base tile is drawn.
[0127] Tile: The base tile is drawn and the remaining area is filled by repeating the base tile such that the right edge of one tile is adjacent to the left edge of the next, and similarly for bottom and top.
[0128] FlipX: The same as Tile, but alternate columns of tiles are flipped horizontally.
[0129] FlipY: The same as Tile, but alternate rows of tiles are flipped vertically.
[0130] FlipXY: A combination of FlipX and FlipY.
[0131] Different tiling modes are described below with reference to FIG. 19.
[0132] A NineGridBrush, described below with reference to FIG. 17 is very similar to an image brush in that it fills an area with a bitmap image. With a NineGridBrush, however, the image is divided into nine regions or grids by four borders. For more information, see the NineGridBrush page.
[0133] FIGS. 3 and 4 show example scene graphs 300 and 400, respectively, including the base object referred to as a Visual. Visual Objects, or simply visuals, are containers for graphical content such as lines, text, and images. As represented in the object inheritance of the visual classes in FIG. 5, there are several different visual objects, including ContainerVisual, which is a Visual that does not directly contain graphical content, but contains child Drawing Visual objects. Child DrawingVisual objects are added to a ContainerVisual rather than to other DrawingVisual objects. This allows the developer to make changes and set properties on individual visual objects without recreating and then re-rendering the entire drawing context, while also allowing access to clipping and transform properties on the container object. ContainerVisual objects can be nested.
[0134] A DrawingVisual is a Visual that can contain graphical content. This Visual exposes a number of drawing methods. The child objects of a DrawingVisual are organized in a zero-based, z-order space. A RetainedVisual is A Visual that introduces a "retained instruction stream" that can be used for drawing. In simpler terms, the RetainedVisual allows the developer to retain the visual's content and redraw it only when necessary. It is possible to use the RetainedVisual imperatively, like a DrawingVisual, by calling RenderOpen and using the returned DrawingContext for drawing. The RetainedVisual provides validation callback functionality and an InvalidateVisual method. To use validation functionality, the user implements the IRetainedRender interface on the RetainedVisual or a class that derives from it.
[0135] Returning to FIG. 5, yet another visual is an HwndVisual 505, which is a Visual used to host a legacy Microsoft.RTM. Win32.RTM. control or window as a child visual inside a visual scene of a scene graph. More particularly, legacy programs will still operate via the WM_PAINT method (or the like) that draws to a child HWnd (or the like) based on prior graphics technology. To support such programs in the new graphics processing model, the HwndVisual allows the Hwnd to be contained in a scene graph and moved as the parent visual is repositioned. Other types of visuals are also feasible, such as three-dimensional (3D) visuals which enable a connection between two-dimensional and three dimensional worlds, e.g., a camera-like view is possible via a two-dimensional visual having a view into a three- dimensional world.
[0136] As shown in FIG. 3, a VisualManager 304 comprises an object that connects a visual tree to a medium. The VisualManager establishes a retained connection between the visual data structure (the root visual 302) and the target to which that data is rendered, offering the possibility of tracking differences between the two. The VisualManager 304 receives window messages and provides methods for transforming a point in drawing coordinates to device coordinates and vice versa.
[0137] A typical application might draw graphics by defining a layout in "XAML" as described in the aforementioned U.S. patent application Ser. No. 10/401,717, and also by specifying some drawing operations in C#. Developers may create Shape elements, or draw geometries using the Geometry classes with primitives. In the following scenario, the code demonstrates drawing an ellipse in the Visual that underlies the Canvas:
22
private void CreateAndShowMainWindow ( ) { mainWindow = new MSAvalon.Windows.Window ( ); Canvas myCanvas = new Canvas( ); mainWindow.Children.Add(myCanvas); Ellipse e1 = new Ellipse( ); e1.Fill = Brushes.Blue; e1.Stroke = Brushes.Black; e1.StrokeThickness = new Length(10); e1.CenterX = new Length(100); e1.CenterY = new Length(75); e1.RadiusX = new Length(50); e1.RadiusY = new Length(50); myCanvas.Children.Add(e1); mainWindow.Show( ); }
[0138] Using the Visual API, developers can instead draw directly into the Visual (that would otherwise be accessed via by the layout element).
[0139] To render the content of a DrawingVisual object, an application typically calls the RenderOpen method on the DrawingVisual. RenderOpen returns a DrawingContext with which the application can perform drawing operations. To clear the Visual's contents, the application calls Close on the DrawingContext. After the application calls Close, the DrawingContext can no longer be used.
[0140] The following code draws an ellipse (the same ellipse as in the previous example) into a DrawingVisual, using a Geometry object rather than the Ellipse shape. The example creates a DrawingVisual, gets the DrawingVisual's DrawingContext, and calls the DrawingContext's DrawGeometry method to draw the ellipse. Note that the developer needs to add the Visual to the visual tree of the top-level object, which in this case is the window.
23
mainWindow = new MSAvalon.Windows.Window( ); mainWindow.Show( ); DrawingVisual myDrawingVisual = new DrawingVisual( ); DrawingContext myDrawingContext = myDrawingVisual.RenderOpen( ); SolidColorBrush mySolidColorBrush = new SolidColorBrush( ); mySolidColorBrush.Color = Colors.Blue; Pen myPen = new Pen(Brushes.Black, 10); EllipseGeometry aGeometry = new EllipseGeometry(new Point (100,75), 50, 50); myDrawingContext.DrawGeometry(mySolidColorBrus- h, myPen, aGeometry); myDrawingContext.Close( ); ((IVisual)mainWindow).Children.Add(myDrawingVisual)
[0141] The following example further builds on the previous example by adding similar ellipses to a ContainerVisual; note that this example is verbose for clarity). Using ContainerVisual can help organize scene objects and allow the developer to segregate Visual objects on which to perform hit-testing or validation (RetainedVisual objects) from ordinary drawn content, and minimize unnecessary redrawing of content.
24
mainWindow = new MSAvalon.Windows.Window( ); mainWindow.Show( ); //Create some Visuals ContainerVisual myContainer = new ContainerVisual( ); DrawingVisual myDrawingVisual = new DrawingVisual( ); DrawingVisual myDrawingVisual_1 = new DrawingVisual( ); DrawingVisual myDrawingVisual_2 = new DrawingVisual( ); //Perform some drawing DrawingContext myDrawingContext = myDrawingVisual.RenderOpen- ( ); SolidColorBrush mySolidColorBrush = new SolidColorBrush( ); mySolidColorBrush.Color = Colors.Violet; Pen myPen = new Pen(Brushes.Black, 10); EllipseGeometry aGeometry = new EllipseGeometry(new Point (100,75), 50, 50); myDrawingContext.DrawGeometry(mySolidColorBrush, myPen, aGeometry); myDrawingContext.Close( ); DrawingContext myDrawingContext_1 = myDrawingVisual_1.RenderOpen( ); mySolidColorBrush.Color = Colors.Red; Pen myPen1 = new Pen(Brushes.Orange, 10); EllipseGeometry aGeometry1 = new EllipseGeometry(new Point (100,175), 50, 50); myDrawingContext_1.DrawGeometry(mySolidColorBrush, myPen1, aGeometry1); myDrawingContext_1.Close( ); DrawingContext myDrawingContext_2 = myDrawingVisual_2.RenderOpen( ); mySolidColorBrush.Color = Colors.Yellow; Pen myPen2 = new Pen(Brushes.Blue, 10); EllipseGeometry aGeometry2 = new EllipseGeometry(new Point (100,275), 50, 50); myDrawingContext_2.DrawGeometry(mySolidColorBrush, myPen2, aGeometry2); myDrawingContext_2.Close( ); //Add DrawingVisuals to the ContainerVisual's VisualCollection myContainer.Children.Add(myDrawingVisual); myContainer.Children.Add(myDrawingVisual_1); myContainer.Children.Add(myDrawingVisual_2); //Add the ContainerVisual to the window ((IVisual)mainWindow).Children.Add(- myContainer);
[0142] A RetainedVisual is similar to a DrawingVisual, but allows for selective redrawing of visual content. As its name suggests, the RetainedVisual can retain content for multiple appearances on the medium. It also provides callback and validation functionality. This functionality can help with rendering performance by offering the developer greater control over re-rendering of content.
[0143] At a basic level, the user can create and use a RetainedVisual much like a DrawingVisual; that is, the user can call RenderOpen and get a DrawingContext. Alternatively, the user can implement the IRetainedRender interface on a RetainedVisual. By doing so, users ensure that the graphics system will use the value set in the RenderBounds property as the bounds for the content to be rendered at the IRetainedVisual.Render call.
[0144] When rendering the scene, the graphics system will examine any child Visual. If the value of the RenderBounds property indicates that a particular Visual's content will be needed in rendering a scene, the system will call IRetainedVisual.Render to fill the content of the Visual, replacing any content already in memory. The application can also call InvalidateVisual directly to flush content from a Visual. If the application has not implemented IRetainedRender on the RetainedVisual, any call to InvalidateVisual will throw an exception.
[0145] The following code instantiates a class that implements IRetainedRender on a RetainedVisual and draws into it.
25
public class Rectangle : RetainedVisual, IRetainedRender { public Rectangle(Color color, Rect rect) : base( ) { m_color = color; m_rect = rect; RenderBounds = rect; } public void SetColor(Color color) { m_color = color; InvalidateVisual( ); } public void Render(DrawingContext ctx) { ctx.DrawRectangle( new SolidColorBrush(m_color), null, m_rect); } }
[0146] The Visual API, like the rest of the graphics system of the present invention, is a managed API and makes use of typical features of managed code, including strong typing and garbage collection. It also takes advantage of the hardware acceleration capability for rendering. To accommodate developers working with existing unmanaged applications, the Visual API provides limited interoperability between the present graphics system and Microsoft Windows.RTM. Graphics Device Interface (GDI)-based rendering services.
[0147] This interoperability allows developers to host GDI-based windows in Visual-aware applications using the Hwnd Visual object, write controls and theming that are based on the present invention's drawing and rendering, but still work in legacy GDI applications, and Modify GDI HWND-based applications to take advantage of the new rendering features, including hardware acceleration and the color model.
[0148] The HwndVisual enables hosting of Win32 content in a Visual-aware application. As represented in FIG. 5, HwndVisual inherits from ContainerVisual. Note that it is not possible to mix GDI and the new drawing models in the same HwndVisual. Instead, this visual might be more useful for legacy controls of limited scope. The following example demonstrates creating a control in an HwndVisual and adding it to the visual tree.
26
//Import Win32 resources and define variables for a control. . . . //Create the control. hwndControl = CreateWindowEx( 0, WC_TREEVIEW, "", WS_CHILD .vertline. WS_VISIBLE .vertline. TVS_HASLINES .vertline. TVS_LINESATROOT .vertline. TVS_HASBUTTONS, x, y, cx, cy, hwndParent, IntPtr.Zero, IntPtr.Zero, 0); //Create an HwndVisual for the control and add it to a previously-defined //collection. s_visual1 = HwndVisual.GetHwndVisual(hwndControl); s_visual1.Size = new Size (150, 150); s_visual1.IsHwndDpiAware = false; s_visual0.Children.Add(s_visual1);
[0149] As with other objects, the developer can apply transforms and other property changes to the control once hosted in a Visual.
27
TransformCollection t = new TransformCollection( ); t.AddScale(1.4, 1.4); t.AddTranslate(130, 80); s_visual0.Children.SetTransform(s_visual1, t);
[0150] As represented in FIG. 3, a top-level (or root) Visual 302 is connected to a Visual manager object 304, which also has a relationship (e.g., via a handle) with a window (HWnd) 306 or similar unit in which graphic data is output for the program code. The VisualManager 304
manages the drawing of the top-level Visual (and any children of that Visual) to that window 306. FIG. 6 shows the VisualManager as one of a set of objects 600 in the object model of the graphics system described herein.
[0151] To draw, the Visual manager 304 processes (e.g., traverses or transmits) the scene graph as scheduled by a dispatcher 308, and provides graphics instructions and other data to the low level component 218 (FIG. 2) for its corresponding window 306, such as generally described in the aforementioned U.S. Patent Applications. The scene graph processing will ordinarily be scheduled by the dispatcher 308 at a rate that is relatively slower than the refresh rate of the lower-level component 218
and/or graphics subsystem 222.
[0152] FIG. 3 shows a number of child Visuals 310-314 arranged hierarchically below the top-level (root) Visual 302, some of which are represented as having been populated via drawing contexts 316, 317 (shown as dashed boxes to represent their temporary nature) with associated instruction lists 318 and 319, respectively, e.g., containing Instruction Lists and other Visuals. The Visuals may also contain other property information. In general, most access on the base visual class comes via an IVisual interface, and visual derives from DependencyObject, as represented in FIG. 5. Among other drawing primitives, the instruction list may include a reference to an ImageData. That ImageData can then be changed/updated directly by getting a drawing context off of it, or by having a SurfaceVisualRenderer (alternatively named ImageDataVisualRenderer).
[0153] Visuals offer services by providing clip, opacity and possibly other properties that can be set, and/or read via a get method. In addition, the visual has flags controlling how it participates in hit testing. A Show property is used to show/hide the visual, e.g., when false the visual is invisible, otherwise the visual is visible. Furthermore, these objects (whether Visuals at the Visual API layer or elements at the element layer) exist in a hierarchy. A coordinate system is inherited down through this hierarchy. In this way, a parent can push a coordinate transform that modifies the rendering pass and gets applied to that parent's children.
[0154] The transform for a visual is on the connection to that visual. In other words, it is set via the [Get.vertline.Set]ChildTransform on the parent's IVisual interface.
[0155] Note that the coordinate transforms may be applied in a uniform way to everything, as if it were in a bitmap. Note that this does not mean that transformations always apply to bitmaps, but that what gets rendered is affected by transforms equally. By way of example, if the user draws a circle with a round pen that is one inch wide and then applies a scale in the X direction of two to that circle, the pen will be two inches wide at the left and right and only one inch wide at the top and bottom. This is sometimes referred to as a compositing or bitmap transform (as opposed to a skeleton or geometry scale that affects the geometry only). FIG. 8 is a representation of scaling transformation, with a non-transformed image 800 appearing on the left and a transformed image 802 with a non-uniform scale appearing on the right. FIG. 9 is a representation of scaling transformation, with the non-transformed image 800 appearing on the left and a transformed image 904 with geometry scaling appearing on the right.
[0156] With respect to coordinate transformation of a visual, TransformToDescendant transforms a point from the reference visual to a descendant visual. The point is transformed from the post-transformation coordinate space of the reference visual to the post-transformation coordinate space of the descendant visual. TransformFromDescendant transforms a point from the descendant visual up the parent chain to the reference visual. The point is transformed from post-transformation coordinate space of the descendant visual to post-transformation coordinate space of the reference visual. A user may get a Matrix to and from a descendant and from and to any arbitrary visual. Two properties are available that may be used to determine the bounding box of the content of the Visual, namely DescendantBounds, which is the bounding box of the descendants, and ContentBounds which is the bounds of the content. Applying a Union to these provides the total bounds.
[0157] The clip property sets (and gets) the clipping region of a visual. Any Geometry (the geometry class is shown in FIG. 10) can be used as a clipping region, and the clipping region is applied in Post-Transformation coordinate space. In one implementation, a default setting for the clipping region is null, i.e., no clipping, which can be thought of as an infinite big clipping rectangle from (-.infin., -.infin.) to (+.infin., +.infin.).
[0158] The Opacity property gets/sets the opacity value of the visual, such that the content of the visual is blended on the drawing surface based on the opacity value and the selected blending mode. The BlendMode property can be used to set (or get) the blending mode that is used. For example, an opacity (alpha) value may be set between 0.0 and 1.0, with linear alpha blending set as the mode, e.g., Color=alpha*foreground color+(1.0-alpha)*background color). Other services, such as special effects properties, may be included in a visual, e.g., blur, monochrome, and so on.
[0159] The various services (including transform, opacity, and clip) can be pushed and popped on a drawing context, and push/pop operations can be nested, as long as there is an appropriate pop call for each push call.
[0160] The PushTransform method pushes a transformation. Subsequent drawing operations are executed with respect to the pushed transformation. The pop call pops the transformation pushed by the matching PushTransform call:
[0161] void PushTransform(Transform transform);
[0162] void PushTransform(Matrix matrix);
[0163] void Pop( );.
[0164] Similarly, the PushOpacity method pushes an opacity value. Subsequent drawing operations are rendered on a temporary surface with the specified opacity value and then composite into the scene. Pop( ) pops the opacity pushed by the matching PushOpacity call:
[0165] void PushOpacity(float opacity);
[0166] void PushOpacity(FloatAnimation opacity);
[0167] void Pop( );.
[0168] The PushClip method pushes a clipping geometry. Subsequent drawing operations are clipped to the geometry. The clipping is applied in post transformation space. Pop( ) pops the clipping region pushed by the matching PushClip call:
[0169] void PushClip(Geometry clip);
[0170] void Popo;.
[0171] Note that push operations can be arbitrarily nested as long as the pop operations are matched with a push. For example, the following is valid:
28
PushTransform(...); DrawLine(...); PushClip(...); DrawLine(...); Pop( ); PushTransform(...); DrawRect(...); Pop( ); Pop( );
[0172] A ProxyVisual is a visual that may be added more than once into the scene graph, e.g., below a container visual. Since any visual referred to by a ProxyVisual may be reached by multiple paths from the root, read services (TransformToDescendent, TransformFromDescendent and HitTest) do not work through a ProxyVisual. In essence, there is one canonical path from any visual to the root of the visual tree and that path does not include any ProxyVisuals.
[0173] FIG. 4 shows an example scene graph 400 in which ContainerVisuals and DrawingVisuals (and others) are related in a scene graph, and have associated data in the form of Instruction Lists, (e.g., in corresponding drawing contexts). The ContainerVisual is a container for Visuals, and ContainerVisuals can be nested into each other. The children of a ContainerVisual can be manipulated can be manipulated with via methods on the IVisual interface that the ContainerVisual implements. The order of the Visuals in the VisualCollection determines in which order the Visuals are rendered, i.e. Visuals are rendered from the lowest index to the highest index from back to front (painting order).
[0174] As described above, visuals can be drawn on by populating their drawing contexts with various drawing primitives, including Geometry, ImageSource and MediaData. Furthermore, there are a set of resources and classes that are shared through this entire stack. This includes Pens, Brushes, Geometry, Transforms and Effects. The DrawingContext abstract class exposes a set of drawing operations that can be used to populate a DrawingVisual, ValidationVisual, ImageData, etc. In other words, the drawing context abstract class exposes a set of drawing operations; for each drawing operation there are two methods, one that takes constants as arguments, and one that takes animators as arguments.
[0175] Geometry is a type of class (FIG. 10) that defines a vector graphics skeleton, without stroke or fill. Each geometry object is a simple shape (LineGeometry, EllipseGeometry, RectangleGeometry), a complex single shape (PathGeometry) or a list of such shapes GeometryCollection with a combine operation (e.g., union, intersection, and so forth) specified. These objects form a class hierarchy as represented in FIG. 10.
[0176] As represented in FIG. 11, the PathGeometry is a collection of Figure objects. In turn, each of the Figure objects is composed of one or more Segment objects which actually define the figure's shape. A Figure is a sub-section of a Geometry that defines a segment collection. This segment collection is a single connected series of two-dimensional Segment objects. The Figure can be either a closed shape with a defined area, or just a connected series of Segments that define a curve, but no enclosed area.
[0177] As represented in FIG. 12, when geometry (e.g., a rectangle) is drawn, a brush or pen can be specified, as described below. Furthermore, the pen object also has a brush object. A brush object defines how to graphically fill a plane, and there is a class hierarchy of brush objects. This is represented in FIG. 12 by the filled rectangle 1202 that results when the visual including the rectangle and brush instructions and parameters is processed. A Pen object holds onto a Brush along with properties for Width, LineJoin, LineCap, MiterLimit, DashArray and DashOffset, as described below. As also described below, some types of Brushes (such as gradients and nine grids) size themselves. When used, the size for these brushes is obtained from the bounding box, e.g., when the GradientUnits/DestinationUnits for the Brush is set to RelativeToBoundingBox, the bounding box of the primitive that is being drawn is used. If those properties are set to Absolute, then the coordinate space is used.
[0178] The graphics object model of the present invention includes a Brush object model, which is generally directed towards the concept of covering a plane with pixels. Examples of types of brushes are represented in the hierarchy of FIG. 13, and, under a Brush base class, include Gradient Brush, NineGridBrush, SolidColorBrush and TileBrush. GradientBrush includes LinearGradient and RadialGradient objects. DrawingBrush and ImageBrush derive from TileBrush. Alternative arrangements of the classes are feasible, e.g., deriving from TileBrush may be ImageBrush, VisualBrush, VideoBrush, NineGridBrush and Drawing Brush. Note that Brush objects may recognize how they relate to the coordinate system when they are used, and/or how they relate to the bounding box of the shape on which they are used. In general, information such as size may be inferred from the object on which the brush is drawn. More particularly, many of the brush types use a coordinate system for specifying some of their parameters. This coordinate system can either be defined as relative to the simple bounding box of the shape to which the brush is applied, or it can be relative to the coordinate space that is active at the time that the brush is used. These are known, respectively, as RelativeToBoundingBox mode and Absolute mode.
[0179] A SolidColorBrush object fills the identified plane with a solid color. If there is an alpha component of the color, it is combined in a multiplicative way with the corresponding opacity attribute in the Brush base class. The following sets forth an example SolidColorBrush object:
29
public sealed class System.Windows.Media.SolidColorBr- ush : Brush { // Constructors public SolidColorBrush( ); // initialize to black public SolidColorBrush(Color color); public SolidColorBrush(System.Windo- ws.Media.Animation.ColorComposer colorComposer); // Properties public Color Color { get; } public IEnumerator ColorAnimations { get; } } public class System.Windows.Media.SolidColorBrushBuilder : BrushBuilder { // Constructors public SolidColorBrushBuilder( ); public SolidColorBrushBuilder(Color color); public SolidColorBrushBuilder(SolidColorBrush scp); // Properties public Color Color { get; set; } public AnimationList ColorAnimations { get; } // Methods public virtual Brush ToBrush( ); }
[0180] The GradientBrush objects, or simply gradients, provide a gradient fill, and are drawn by specifying a set of gradient stops, which specify the colors along some sort of progression. The gradient is by drawn by performing linear interpolations between the gradient stops in a gamma 2.2 RGB color space; interpolation through other gammas or other color spaces (HSB, CMYK and so forth, is also a feasible alternative. Two types of gradient objects include linear and radial gradients.
[0181] In general, gradients are composed of a list of gradient stops. Each of these gradient stops contains a color (with the included alpha value) and an offset. If there are no gradient stops specified, the brush is drawn as a solid transparent black, as if there were no brush specified at all. If there is only one gradient stop specified, the brush is drawn as a solid color with the one color specified. Like other resource classes, the gradient stop class (example in the table below) is derives from the changeable class and thus is selectively mutable, as described in the United States Patent Application entitled "Changeable Class and Pattern to Provide Selective Mutability in Computer Programming Environments."
[0182] Gradients are drawn by specifying a set of gradient stops. These gradient stops specify the colors along some sort of progression. There are two types of gradients presently supported, namely linear and radial gradients. The gradient is drawn by doing interpolations between the gradient stops in the specified color space.
[0183] Gradients are composed of a list of gradient stops. Each of these gradient stops contains a color (with the included alpha value) and an offset. If there are no gradient stops specified, the brush is drawn as transparent (as if there were no brush specified). If there is only one gradient stop specified, the brush is drawn as a solid color with the one color specified. Any gradient stops with offsets in the range of zero to one (0.0 . . . 1.0) are considered, with the largest stop in the range (-.infin. . . . 0.0] and the smallest stop in the range [1.0 . . . +.infin.). If the set of stops being considered includes a stop which is outside of the range zero to one, an implicit stop is derived at zero (and/or one) which represents the interpolated color which would occur at this stop. Also, if two or more stops are set at the same offset, a hard transition (rather than interpolated) occurs at that offset. The order in which stops are added determines the behavior at this offset; the first stop to be added is the effective color before that offset, the last stop to be set is the effective color after this stop, and any additional stops at this offset are ignored.
[0184] This class is a Changeable like other resource classes:
30
public sealed class System.Windows.Media.GradientStop : Changeable { public GradientStop( ); public GradientStop(Color color, double offset); public GradientStop(Color color, ColorAnimationCollection colorAnimations, double offset, DoubleAnimationCollection offsetAnimations); public new GradientStop Copy( ); // hides Changeable.Copy( ) // Default is transparent [Animation("ColorAnimations")] public Color Color { get; set; } public ColorAnimationCollection ColorAnimations { get; set; } // Default is 0
[Animation("OffsetAnimations")] public double Offset { get; set; } public DoubleAnimationCollecti- on OffsetAnimations { get; set; } }
[0185] Like SolidColorBrush, this has nested Changeables in the animation collections.
[0186] The GradientSpreadMethod enum specifies how the gradient should be drawn outside of the specified vector or space. There are three possible values, including Pad, in which the end colors (first and last) are used to fill the remaining space, Reflect, in which the stops are replayed in reverse order repeatedly to fill the space, and Repeat, in which the stops are repeated in order until the space is filled. The default value for properties of this type is Pad:
31
public enum System.Windows.Media.GradientSpreadMethod { Pad, Reflect, Repeat }
[0187] FIGS. 14 and 15 provide some GradientSpreadMethod examples, (albeit in grayscale rather than in color). Each shape has a linear gradient going from white to grey. The solid line represents the gradient vector.
[0188] In general, a LinearGradientBrush is used to fill an area with a linear gradient. A linear gradient defines a gradient along a line, The line's end point is defined by the linear gradient's StartPoint and EndPoint properties. By default, the StartPoint of a linear gradient is (0,0), the upper-left corner of the area being filled, and its EndPoint is (1,1), the bottom-right corner of the area being filled. As represented in FIG. 15, using the default values, the colors in the resulting gradient are interpolated along a diagonal path. The black line formed from the start and end points of the gradient has been added herein to highlight the gradient's interpolation path.
[0189] The ColorInterpolationMode enum defines the interpolation mode for colors within a gradient. The two options are PhysicallyLinearGamma10 and PerceptuallyLinearGamma22.
32
public enum ColorInterpolationMode { // Colors are interpolated in Gamma 1.0 space PhysicallyLinearGamma10, // Colors are interpolated in Gamma 2.2
space PerceptuallyLinearGamma22
}
[0190] This is an abstract base class.
33
public abstract class System.Windows.Media.GradientBr- ush : Brush { internal GradientBrush( ); public new GradientBrush Copy( ); // hides Changeable.Copy( ) // Default is "PerceptuallyLinearGamma22" public ColorInterpolationMode ColorInterpolationMode { get; set; } // Default is RelativeToBoundingBox public BrushMappingMode MappingMode { get; set; } // Default is Pad public GradientSpreadMethod SpreadMethod { get; set; } // Gradient Stops public void AddStop(Color color, double offset); public GradientStopCollection GradientStops { get; set; } // ColorInterpolationMode public ColorInterpolationMode ColorInterpolationMode { get; set; } }
[0191] As described above in the Changeables section, GradientBrush is a complex-type with respect to Changeables, because its GradientStops property itself holds Changeables. That means that GradientBrush needs to implement the protected methods MakeUnchangeableCore( ), and PropagateEventHandler( ), as well as CloneCore( ) that Changeable subclasses implement. It may also choose to implement ValidateObjectState( ) if there are invalid combinations of GradientStops that make up the collection, for instance.
[0192] The LinearGradient specifies a linear gradient brush along a vector. The individual stops specify colors stops along that vector.
34
public sealed class System.Windows.Media.LinearGradie- nt : Gradient Brush { public LinearGradient( ); // initializes to transparent // Sets up a gradient with two colors and a gradient vector // specified to fill the object the gradient is applied to. // This implies RelativeToBoundingBox for the GradientUnits // property public LinearGradient(Color color1, Color color2, double angle); public LinearGradient (Color color1, Color color2, Point vectorStart, Point vectorEnd); public new LinearGradient Copy( ); // hides Changeable.Copy( ) // Gradient Vector Start Point // Default is 0,0
[Animation("StartPointAnima- tions")] public Point StartPoint { get; set; } public PointAnimationCollection StartPointAnimations { get; set; } // Default is 1,1
[Animation("EndPointAnimations")] public Point EndPoint { get; set; } public PointAnimationCollection EndPointAnimations { get; set; } } linear-gradient-brush: "HorizontalGradient" comma-wsp color comma-wsp color .vertline. "VerticalGradient" comma-wsp color comma-wsp color .vertline. "LinearGradient" comma-wsp coordinate-pair comma-wsp color comma-wsp color
[0193] The markup for LinearGradient allows specification of a LinearGradient with two color stops, at offsets zero and one. If the "LinearGradient" version is used, the start point and end point are specified, respectively. If "HorizontalGradient" is used, the start point is set to 0,0 and the end point is set to 1,0. If "VerticalGradient" is used, the start point is set to 0,0 and the end point is set to 0,1. In these cases, the default MappingMode is used, which is RelativeToBoundingBox.
[0194] The RadialGradient is similar in programming model to the linear gradient. However, whereas the linear gradient has a start and end point to define the gradient vector, the radial gradient has a circle along with a focal point to define the gradient behavior. The circle defines the end point of the gradient--in other words, a gradient stop at 1.0
defines the color at the circle's circumference. The focal point defines center of the gradient. A gradient stop at 0.0 defines the color at the focal point. FIG. 16 represents a RadialGradient that (in grayscale) goes from white to grey. The outside circle represents the gradient circle while the solid dot denotes the focal point. This gradient has SpreadMethod set to Pad.
35
public sealed class System.Windows.Media.RadialGradie- nt : GradientBrush { public RadialGradient( ); // initialize to transparent // Sets up a gradient with two colors. // This implies RelativeToBoundingBox for the Gradient Units // property along with a center at (0.5,0.5) // a radius of 0.5 and a focal point at (0.5,0.5) public RadialGradient (Color color1, Color color2); public new RadialGradient Copy( ); // hides Changeable.Copy( ) // Default is 0.5,0.5
[Animation("CenterAnimations")] public Point Center { get; set; } public PointAnimationCollection CenterAnimations { get; set; } // Default is 0.5
[Animation("RadiusXAnimations")] public double RadiusX { get; set; } public DoubleAnimationCollection RadiusXAnimations { get; set; } // Default is 0.5
[Animation("RadiusYAnima- tions")] public double RadiusY { get; set; } public DoubleAnimationCollection RadiusYAnimations { get; set; } // Default is 0.5,0.5
[Animation("FocusAnimations")] public Point Focus { get; set; } public PointAnimationCollection FocusAnimations { get; set; } }
[0195] The markup for RadialGradient allows specification of a RadialGradient with two color stops, at offsets 0 and 1 respectively. The default MappingMode is used, which is RelativeToBoundingBox, as are the default radii, 0.5:
36
radial-gradient-brush: "RadialGradient" comma-wsp color comma-wsp color
[0196] The TileBrush is an abstract base class which contains logic to describe a tile and a means by which that tile should fill an area. Subclasses of TileBrush contain content, and logically define a way to fill an infinite plane.
[0197] The Stretch enum is used to describe how a ViewBox (source coordinate space) is mapped to a ViewPort (destination coordinate space). This is used in TileBrush:
37
public enum System.Windows.Stretch { // Preserve original size None, // Aspect ratio is not preserved, ViewBox fills ViewPort Fill, // Aspect ratio is preserved, VewBox is uniformly scaled as large as // possible such that both width and height fit within ViewPort Uniform, // Aspect ratio is preserved, VewBox is uniformly scaled as small as // possible such that the entire ViewPort is filled by the ViewBox UniformToFill }
[0198] FIG. 18 provides stretch examples. In these examples, the contents are top/left aligned.
[0199] The TileMode enum is used to describe if and how a space is filled by Tiles. A TileBrush defines where the base Tile is (specified by the ViewPort). The rest of the space is filled based on the TileMode value.
38
public enum System.Windows.Media.TileMode { // Do not tile - only the base tile is drawn, the remaining area is // left as transparent None, // The basic tile mode - the base tile is drawn and the remaining area // is filled by repeating the base tile such that