9 --> |
9 --> |
10 <!DOCTYPE concept |
10 <!DOCTYPE concept |
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
12 <concept xml:lang="en" id="GUID-39CFE2E2-9776-54EE-8E3B-8B85AFF1697A"><title>Window Server Plug-in Framework in the Non-ScreenPlay Variant</title><shortdesc>This topic provides an introduction to the Window Server plug-in framework in the non-ScreenPlay variant. This framework was introduced in a project to improve the Window Server. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p> <b>Variant</b>: <xref href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita">Non-ScreenPlay</xref>. <b>Target audience</b>: Device creators. </p> <section><title>Purpose</title> <p>The Window Server (WSERV) performance improvements introduce several new APIs and Service Provider Interfaces (SPIs). An SPI differs from an API in that an API describes functionality that a developer expects to use, whereas an SPI defines an interface that a developer is expected to implement. </p> <p>The SPI part consists primarily of abstract interfaces for plug-ins, faders and render stages. Developers are expected to provide concrete implementations of these interfaces. The API part consists of new object provider interfaces that can be used by plug-ins (including the existing Content Rendering Plug-ins (CRP)). </p> <p>This document provides an overview for the new WSERV performance improvements. </p> </section> <section><title>Library details</title> <p>There is one library affected by the WSERV performance improvements changes. </p> <table id="GUID-9CB1253D-AABA-5B2E-9E2D-78E95F84DBC2"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Library Name</entry> <entry>Short Description</entry> </row> </thead> <tbody><row><entry><p> <filepath>wsgraphicdrawer.lib </filepath> </p> </entry> <entry><p>Server-side base-classes for graphic drawer plug-ins </p> </entry> </row> </tbody> </tgroup> </table> </section> <section><title>Architectural relationship</title> <p><b>New additions </b> </p> <p>In the past, Window Server (WSERV) has supported a number of plug-in interfaces, for example: </p> <ul><li id="GUID-CD8F335E-B5CE-5E01-ADE4-B74ECA118A58"><p>Anim dlls </p> </li> <li id="GUID-1668ACD9-AA34-535E-877C-9EDB3F81730F"><p>Content rendering plug-ins </p> </li> </ul> <p>In general, these plug-ins enable UI platform providers to have code running in the WSERV process for specific purposes, without having to modify WSERV. This mechanism can be used to extend or customize WSERV functionality. However, in the past, new plug-in types were added in a fairly ad hoc way, with each new implementer going about things in a different way. </p> <p>In order to improve performance, there have been changes made to this previous method. These changes are a generic plug-in framework, two new types of plug-in and some new extension interfaces. </p> <p><b>A generic plug-in framework </b> </p> <p>The generic plug-in framework provides a standard mechanism for adding new types of plug-ins, based on the support provided by the Symbian ECOM component. This amounts to a fairly thin wrapper around ECOM, with WSERV specific features such as the ability to specify which plug-ins to load at boot time, using the <codeph>WSINI.INI</codeph> file. The intention is that when new types of plug-in are introduced in future they should use this generic plug-in framework rather than an ad hoc mechanism, leading to reduced implementation time. </p> <p><b>Two new types of plug-in </b> </p> <p>The WSERV performance improvements make use of the new framework to add two new types of plug-in: </p> <ul><li id="GUID-D2FF6AA8-5BDB-5033-8482-CAC6D50C13C5"><p>Fader plug-ins, which enable customizable fading </p> </li> <li id="GUID-5B8F8A9F-D956-5AD2-819F-493BD55767E1"><p>Render stage plug-ins, which enable modification of the tail end of the rendering pipeline, at the point where WSERV outputs draw operations for a screen target. </p> </li> </ul> <p><b>New extension interfaces </b> </p> <p>The WSERV performance improvements also provide a number of new extension interfaces giving plug-ins a more detailed picture than previously of WSERV’s internal workings. This applies not only to plug-ins using the new framework, but also to the existing CRP plug-ins. </p> </section> <section><title>APIs and SPIs</title> <p>To understand the new SPIs, it is necessary to show how they would fit into a configuration in which concrete implementations have been supplied by plug-ins. The following diagram shows the default configuration, in which the concrete classes are supplied by the WSERV reference plug-ins: </p> <fig id="GUID-567069E8-347C-59B3-A340-20F99BA43721"><title> |
12 <concept xml:lang="en" id="GUID-39CFE2E2-9776-54EE-8E3B-8B85AFF1697A"><title>Window Server Plug-in Framework in the Non-ScreenPlay Variant</title><shortdesc>This topic provides an introduction to the Window Server plug-in framework in the non-ScreenPlay variant. This framework was introduced in a project to improve the Window Server. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p> <b>Variant</b>: <xref href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita">Non-ScreenPlay</xref>. <b>Target audience</b>: Device creators. </p> <section><title>Purpose</title> <p>The Window Server (WSERV) performance improvements introduce several new APIs and Service Provider Interfaces (SPIs). An SPI differs from an API in that an API describes functionality that a developer expects to use, whereas an SPI defines an interface that a developer is expected to implement. </p> <p>The SPI part consists primarily of abstract interfaces for plug-ins, faders and render stages. Developers are expected to provide concrete implementations of these interfaces. The API part consists of new object provider interfaces that can be used by plug-ins (including the existing Content Rendering Plug-ins (CRP)). </p> <p>This document provides an overview for the new WSERV performance improvements. </p> </section> <section><title>Library details</title> <p>There is one library affected by the WSERV performance improvements changes. </p> <table id="GUID-9CB1253D-AABA-5B2E-9E2D-78E95F84DBC2"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Library Name</entry> <entry>Short Description</entry> </row> </thead> <tbody><row><entry><p> <filepath>wsgraphicdrawer.lib </filepath> </p> </entry> <entry><p>Server-side base-classes for graphic drawer plug-ins </p> </entry> </row> </tbody> </tgroup> </table> </section> <section><title>Architectural relationship</title> <p><b>New additions </b> </p> <p>In the past, Window Server (WSERV) has supported a number of plug-in interfaces, for example: </p> <ul><li id="GUID-CD8F335E-B5CE-5E01-ADE4-B74ECA118A58"><p>Anim dlls </p> </li> <li id="GUID-1668ACD9-AA34-535E-877C-9EDB3F81730F"><p>Content rendering plug-ins </p> </li> </ul> <p>In general, these plug-ins enable UI platform providers to have code running in the WSERV process for specific purposes, without having to modify WSERV. This mechanism can be used to extend or customize WSERV functionality. However, in the past, new plug-in types were added in a fairly ad hoc way, with each new implementer going about things in a different way. </p> <p>In order to improve performance, there have been changes made to this previous method. These changes are a generic plug-in framework, two new types of plug-in and some new extension interfaces. </p> <p><b>A generic plug-in framework </b> </p> <p>The generic plug-in framework provides a standard mechanism for adding new types of plug-ins, based on the support provided by the Symbian ECOM component. This amounts to a fairly thin wrapper around ECOM, with WSERV specific features such as the ability to specify which plug-ins to load at boot time, using the <codeph>WSINI.INI</codeph> file. The intention is that when new types of plug-in are introduced in future they should use this generic plug-in framework rather than an ad hoc mechanism, leading to reduced implementation time. </p> <p><b>Two new types of plug-in </b> </p> <p>The WSERV performance improvements make use of the new framework to add two new types of plug-in: </p> <ul><li id="GUID-D2FF6AA8-5BDB-5033-8482-CAC6D50C13C5"><p>Fader plug-ins, which enable customizable fading </p> </li> <li id="GUID-5B8F8A9F-D956-5AD2-819F-493BD55767E1"><p>Render stage plug-ins, which enable modification of the tail end of the rendering pipeline, at the point where WSERV outputs draw operations for a screen target. </p> </li> </ul> <p><b>New extension interfaces </b> </p> <p>The WSERV performance improvements also provide a number of new extension interfaces giving plug-ins a more detailed picture than previously of WSERV’s internal workings. This applies not only to plug-ins using the new framework, but also to the existing CRP plug-ins. </p> </section> <section><title>APIs and SPIs</title> <p>To understand the new SPIs, it is necessary to show how they would fit into a configuration in which concrete implementations have been supplied by plug-ins. The following diagram shows the default configuration, in which the concrete classes are supplied by the WSERV reference plug-ins: </p> <fig id="GUID-567069E8-347C-59B3-A340-20F99BA43721"><title> |
13 Default configuration of WSERV plug-ins |
13 Default configuration of WSERV plug-ins |
14 </title> <image href="GUID-7F200AB2-602E-5351-8FA1-1B818F6DE355_d0e245815_href.png" placement="inline"/></fig> <p>The diagram has three layers, going down: </p> <ol id="GUID-76FDE51A-794E-52AC-B718-5AF61F692825"><li id="GUID-7B3FCB2E-54D7-5739-BDE4-7B6BFA5722D2"><p>The top layer is the <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref> interface, which is an existing class in WSERV. This provides a framework for extensible interfaces. </p> </li> <li id="GUID-C124D68E-B08F-52E9-B5C8-AA179C0DE1AA"><p>In the middle layer, there are four new interfaces introduced by the WSERV performance improvements: <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref>, <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref>, <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref> and <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref>. </p> </li> <li id="GUID-D926A8DC-779D-56F2-BFF5-2060DDBEA93E"><p>In the bottom layer, there are the concrete implementations of the new interfaces. </p> </li> </ol> <p>The classes in the above diagram are as follows: </p> <ul><li id="GUID-214F1492-8998-59CE-96C5-5AA82F96B4C8"><p> <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> is the base class from which the top level objects presented by plug-ins should derive. </p> </li> <li id="GUID-0717B186-7404-5F21-A9A4-428DDBB1CB8F"><p> <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref> is the interface that the plug-in object in a fader plug-in should present. Thus the concrete implementation of a fader should derive from <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> and <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref>. </p> </li> <li id="GUID-7BD0FDC1-1862-55A0-8B16-F649E6C569E9"><p> <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref> is the interface that the plug-in object in a render stage plug-in should present. Thus concrete implementations of render stage factories should derive from <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> and <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref>. </p> </li> <li id="GUID-B3B3A50F-E6EF-5B65-AC6D-542363E00891"><p> <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref> is the abstract base class for render stages. Concrete implementations should derive from this. (Note that <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref> is *not* a subclass of <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref>. The plug-in provides only a render stage factory. Render stages must then be obtained from the factory.) </p> </li> </ul> <p>Why do render stages have factories, but faders do not? The idea here is that faders are not expected to have any internal state, and therefore a single fader instance can be shared across multiple screens. Therefore there is no need for a factory. On the other hand, render stages could have internal state (such as stored draw commands or offscreen bitmaps), and therefore each screen needs its own instance. Therefore we need a factory to create the instances as required. </p> <p>Note that in addition, we may want multiple render stages (of different types) per screen, if they are chained. Therefore we will typically have multiple render stage factories. For example, in the default configuration, there are two render stage factory plug-ins, producing flicker buffer and standard render stages respectively. </p> <p><b>New object provider extensions </b> </p> <p>In addition to the above, the WSERV performance improvements provide some minor extensions to existing object provider interfaces, together with the following new object provider extension interfaces: </p> <ul><li id="GUID-391069BC-422E-50ED-A4C2-F6E649FFCFB1"><p> <xref href="GUID-5A22BB23-DF2D-3E1C-9476-A485C878283D.dita"><apiname>MWsWindow</apiname></xref> – an interface through which windows can be examined </p> </li> <li id="GUID-8D4E169B-3C7B-528B-AEA4-5FB9618BD2F1"><p> <xref href="GUID-51B49D4D-A421-3AE9-A7D6-F4B89CEE0704.dita"><apiname>MWsScreenRedraw</apiname></xref> – an extension of the existing <xref href="GUID-6021D388-FFC5-3D4E-B0D0-4C579D500DD0.dita"><apiname>MWsScreen</apiname></xref> interface for handling the animation aspects of the redraw sequence </p> </li> <li id="GUID-06A315C4-F503-5F2E-A250-90B36D2C1CA8"><p> <xref href="GUID-4D4CEEB6-940A-3016-9BD9-70EE69BA2BD1.dita"><apiname>MWsScreenRedrawObserver</apiname></xref> – an interface for receiving notifications of screen updates </p> </li> <li id="GUID-70D71FA4-1C95-5BAC-B783-FADC817557F1"><p> <xref href="GUID-112D3118-4983-3BC5-B4E8-0FB219E03295.dita"><apiname>MWsMemoryRelease</apiname></xref> – an interface which enables plug-ins to cooperate with WSERV by releasing memory when requested (for example caches) </p> </li> <li id="GUID-EE5FE016-09EC-5149-B1CE-51F6A81D5689"><p> <xref href="GUID-7A56E7FD-9BC3-33E7-8DC8-EB9F39773DF3.dita"><apiname>MWsGcClipRect</apiname></xref> – an extension interface that can be requested from an <xref href="GUID-658CCB93-7143-3D51-BD34-B43AFA578958.dita"><apiname>MWsGc</apiname></xref>, providing some functionality to do with clipping rectangles which was omitted from the original <xref href="GUID-658CCB93-7143-3D51-BD34-B43AFA578958.dita"><apiname>MWsGc</apiname></xref> implementation </p> </li> <li id="GUID-E1E43A73-F574-57F5-B7AF-6EBCECF9AF45"><p> <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref> – enables plug-ins to request services from other plug-ins </p> </li> <li id="GUID-CDBD37E5-EF22-5206-8A6E-0E067CA20689"><p> <xref href="GUID-C15F47F9-7C13-302B-AD81-FBB288102AAA.dita"><apiname>MWsIniFile</apiname></xref> – enables plug-ins to read the <codeph>WSINI.INI</codeph> file </p> </li> </ul> <p>Each of these new interfaces inherits from the existing <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref> interface, and they are made available through the object provider mechanism. In other words, each interface has an associated “type id”, and the interface is obtained by calling <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita#GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F/GUID-DC742E6F-6F18-3B1E-A3B7-B4A1A7E258DE"><apiname>MWsObjectProvider::ResolveObjectInterface(<type id>)</apiname></xref> on an appropriate object provider. In the case where a plug-in wants to request the interface, the object provider will be WSERV’s <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref>, which is passed to plug-ins during construction. </p> </section> <section><title>Fader plug-ins</title> <p>Fader plug-ins enable WSERV to delegate the implementation of window fading. This means that when <codeph>RWindowTreeNode::SetFaded()</codeph> or <codeph>RWindowBase::FadeBehind()</codeph> is called on the client side, WSERV calls the fader plug-in to do the fading. Note that fader plug-ins are <b>not</b> involved in <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> fading. Calls to <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-64B8B22D-3702-32F9-9B42-3A5B2A95AABE"><apiname>CWindowGc::SetFaded()</apiname></xref> do not result in calls to fader plug-ins – WSERV passes them straight through to the rendering backend as GDI calls. </p> <p>In principle, fader plug-ins enable the implementation of custom fading algorithms. However, one potential limitation at the moment is that the existing client-side APIs dictate the form that parameters to control fading must take - therefore <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-A093EB4F-EA64-368D-B4BE-F5A4568F63B4"><apiname>RWsSession::SetDefaultFadingParameters(TUint8 |
14 </title> <image href="GUID-7F200AB2-602E-5351-8FA1-1B818F6DE355_d0e251826_href.png" placement="inline"/></fig> <p>The diagram has three layers, going down: </p> <ol id="GUID-76FDE51A-794E-52AC-B718-5AF61F692825"><li id="GUID-7B3FCB2E-54D7-5739-BDE4-7B6BFA5722D2"><p>The top layer is the <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref> interface, which is an existing class in WSERV. This provides a framework for extensible interfaces. </p> </li> <li id="GUID-C124D68E-B08F-52E9-B5C8-AA179C0DE1AA"><p>In the middle layer, there are four new interfaces introduced by the WSERV performance improvements: <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref>, <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref>, <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref> and <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref>. </p> </li> <li id="GUID-D926A8DC-779D-56F2-BFF5-2060DDBEA93E"><p>In the bottom layer, there are the concrete implementations of the new interfaces. </p> </li> </ol> <p>The classes in the above diagram are as follows: </p> <ul><li id="GUID-214F1492-8998-59CE-96C5-5AA82F96B4C8"><p> <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> is the base class from which the top level objects presented by plug-ins should derive. </p> </li> <li id="GUID-0717B186-7404-5F21-A9A4-428DDBB1CB8F"><p> <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref> is the interface that the plug-in object in a fader plug-in should present. Thus the concrete implementation of a fader should derive from <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> and <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref>. </p> </li> <li id="GUID-7BD0FDC1-1862-55A0-8B16-F649E6C569E9"><p> <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref> is the interface that the plug-in object in a render stage plug-in should present. Thus concrete implementations of render stage factories should derive from <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> and <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref>. </p> </li> <li id="GUID-B3B3A50F-E6EF-5B65-AC6D-542363E00891"><p> <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref> is the abstract base class for render stages. Concrete implementations should derive from this. (Note that <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref> is *not* a subclass of <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref>. The plug-in provides only a render stage factory. Render stages must then be obtained from the factory.) </p> </li> </ul> <p>Why do render stages have factories, but faders do not? The idea here is that faders are not expected to have any internal state, and therefore a single fader instance can be shared across multiple screens. Therefore there is no need for a factory. On the other hand, render stages could have internal state (such as stored draw commands or offscreen bitmaps), and therefore each screen needs its own instance. Therefore we need a factory to create the instances as required. </p> <p>Note that in addition, we may want multiple render stages (of different types) per screen, if they are chained. Therefore we will typically have multiple render stage factories. For example, in the default configuration, there are two render stage factory plug-ins, producing flicker buffer and standard render stages respectively. </p> <p><b>New object provider extensions </b> </p> <p>In addition to the above, the WSERV performance improvements provide some minor extensions to existing object provider interfaces, together with the following new object provider extension interfaces: </p> <ul><li id="GUID-391069BC-422E-50ED-A4C2-F6E649FFCFB1"><p> <xref href="GUID-5A22BB23-DF2D-3E1C-9476-A485C878283D.dita"><apiname>MWsWindow</apiname></xref> – an interface through which windows can be examined </p> </li> <li id="GUID-8D4E169B-3C7B-528B-AEA4-5FB9618BD2F1"><p> <xref href="GUID-51B49D4D-A421-3AE9-A7D6-F4B89CEE0704.dita"><apiname>MWsScreenRedraw</apiname></xref> – an extension of the existing <xref href="GUID-6021D388-FFC5-3D4E-B0D0-4C579D500DD0.dita"><apiname>MWsScreen</apiname></xref> interface for handling the animation aspects of the redraw sequence </p> </li> <li id="GUID-06A315C4-F503-5F2E-A250-90B36D2C1CA8"><p> <xref href="GUID-4D4CEEB6-940A-3016-9BD9-70EE69BA2BD1.dita"><apiname>MWsScreenRedrawObserver</apiname></xref> – an interface for receiving notifications of screen updates </p> </li> <li id="GUID-70D71FA4-1C95-5BAC-B783-FADC817557F1"><p> <xref href="GUID-112D3118-4983-3BC5-B4E8-0FB219E03295.dita"><apiname>MWsMemoryRelease</apiname></xref> – an interface which enables plug-ins to cooperate with WSERV by releasing memory when requested (for example caches) </p> </li> <li id="GUID-EE5FE016-09EC-5149-B1CE-51F6A81D5689"><p> <xref href="GUID-7A56E7FD-9BC3-33E7-8DC8-EB9F39773DF3.dita"><apiname>MWsGcClipRect</apiname></xref> – an extension interface that can be requested from an <xref href="GUID-658CCB93-7143-3D51-BD34-B43AFA578958.dita"><apiname>MWsGc</apiname></xref>, providing some functionality to do with clipping rectangles which was omitted from the original <xref href="GUID-658CCB93-7143-3D51-BD34-B43AFA578958.dita"><apiname>MWsGc</apiname></xref> implementation </p> </li> <li id="GUID-E1E43A73-F574-57F5-B7AF-6EBCECF9AF45"><p> <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref> – enables plug-ins to request services from other plug-ins </p> </li> <li id="GUID-CDBD37E5-EF22-5206-8A6E-0E067CA20689"><p> <xref href="GUID-C15F47F9-7C13-302B-AD81-FBB288102AAA.dita"><apiname>MWsIniFile</apiname></xref> – enables plug-ins to read the <codeph>WSINI.INI</codeph> file </p> </li> </ul> <p>Each of these new interfaces inherits from the existing <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref> interface, and they are made available through the object provider mechanism. In other words, each interface has an associated “type id”, and the interface is obtained by calling <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita#GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F/GUID-DC742E6F-6F18-3B1E-A3B7-B4A1A7E258DE"><apiname>MWsObjectProvider::ResolveObjectInterface(<type id>)</apiname></xref> on an appropriate object provider. In the case where a plug-in wants to request the interface, the object provider will be WSERV’s <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref>, which is passed to plug-ins during construction. </p> </section> <section><title>Fader plug-ins</title> <p>Fader plug-ins enable WSERV to delegate the implementation of window fading. This means that when <codeph>RWindowTreeNode::SetFaded()</codeph> or <codeph>RWindowBase::FadeBehind()</codeph> is called on the client side, WSERV calls the fader plug-in to do the fading. Note that fader plug-ins are <b>not</b> involved in <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> fading. Calls to <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-64B8B22D-3702-32F9-9B42-3A5B2A95AABE"><apiname>CWindowGc::SetFaded()</apiname></xref> do not result in calls to fader plug-ins – WSERV passes them straight through to the rendering backend as GDI calls. </p> <p>In principle, fader plug-ins enable the implementation of custom fading algorithms. However, one potential limitation at the moment is that the existing client-side APIs dictate the form that parameters to control fading must take - therefore <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-A093EB4F-EA64-368D-B4BE-F5A4568F63B4"><apiname>RWsSession::SetDefaultFadingParameters(TUint8 |
15 aBlackMap,TUint8 aWhiteMap)</apiname></xref> has to be used. In addition, <xref href="GUID-9FFD28C7-8747-3438-84BF-44AF26ACEC7D.dita#GUID-9FFD28C7-8747-3438-84BF-44AF26ACEC7D/GUID-317255C3-6CB3-3608-8104-53706BDBAFA0"><apiname>RWindowTreeNode::SetFaded()</apiname></xref> has a variant in which these parameters can be passed in. The API that fader plug-ins present to WSERV has been designed so that fading parameters can be passed as opaque binary data. However, as it stands this data will always take the form of two <xref href="GUID-F894527F-13A6-3E6D-BA7B-187812CDF20E.dita"><apiname>TUint8</apiname></xref> s. </p> <p> <b>Note</b>: In ScreenPlay, fading effects can be created using render stages. See <xref href="GUID-E7F6DD98-9080-50E9-B071-56247EBBF570.dita">Window Server Plugins Component</xref> for more information. </p> </section> <section><title>Render stage plug-ins</title> <p>Render stage plug-ins are designed to allow the customizations of the final stages of the rendering pipeline. The idea is that, to WSERV, a render stage looks pretty much like the graphics context that it is expecting to use to draw to a screen. WSERV carries on with its usual tasks, tracking dirty rectangles and so on, and issuing draw operations when it believes that it needs to repaint some region of the screen. However, instead of these draw operations being used immediately to repaint the screen, they are passed to a render stage. The simplest render stage implementation would indeed use the draw operations to repaint the screen. However, the render stage may do other things with the draw operations, such as capturing some of them for later use in a transition effect or redirecting them to another target and so on. </p> <p>The render stage API is such that every time WSERV wants to do a redraw, it must call <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-75503F6F-91DA-3392-8CD5-34FFF9095D30"><apiname>CWsRenderStage::Begin()</apiname></xref> in order to get hold of the graphics context with which to do the drawing. When it is finished, it must call <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-0EBA06BF-D17F-3485-85B6-F4B855A48B62"><apiname>CWsRenderStage::End()</apiname></xref>, and release its pointer to the graphics context. This means in particular that render stages understand that draw operations come in blocks corresponding to a single redraw. </p> <p>Render stages can be chained, so that the output of the first render stage (in the form of draw operations), passes not to the screen but to a second render stage. In the default implementation supplied with WSERV, two render stages are used to achieve flicker-free drawing. The first render stage takes the draw operations that are passed in, and draws them to an offscreen bitmap. When <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-0EBA06BF-D17F-3485-85B6-F4B855A48B62"><apiname>CWsRenderStage::End()</apiname></xref> is called, it then blits the updated region to the second render stage. The second render stage draws to the screen. This setup therefore eliminates flicker within individual redraws. </p> <p>For information about render stages in ScreenPlay, see <xref href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita">ScreenPlay Render Stages</xref>. </p> </section> <section><title>Key classes</title> <p>All classes belong to <codeph>wsgraphicdrawer.lib</codeph>. </p> <table id="GUID-57A9F34C-D432-51E9-BC55-06E69A29380E"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Class name</entry> <entry>Description</entry> </row> </thead> <tbody><row><entry><p> <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> </p> </entry> <entry><p>This is the base class that all top-level plug-in objects must derive from. Note that it is an abstract class – in particular it does not provide an implementation of <xref href="GUID-311158DA-BA24-3CF2-8361-EE36F07EED4B.dita"><apiname>ResolveObjectInterface() |
15 aBlackMap,TUint8 aWhiteMap)</apiname></xref> has to be used. In addition, <xref href="GUID-9FFD28C7-8747-3438-84BF-44AF26ACEC7D.dita#GUID-9FFD28C7-8747-3438-84BF-44AF26ACEC7D/GUID-317255C3-6CB3-3608-8104-53706BDBAFA0"><apiname>RWindowTreeNode::SetFaded()</apiname></xref> has a variant in which these parameters can be passed in. The API that fader plug-ins present to WSERV has been designed so that fading parameters can be passed as opaque binary data. However, as it stands this data will always take the form of two <xref href="GUID-F894527F-13A6-3E6D-BA7B-187812CDF20E.dita"><apiname>TUint8</apiname></xref> s. </p> <p> <b>Note</b>: In ScreenPlay, fading effects can be created using render stages. See <xref href="GUID-E7F6DD98-9080-50E9-B071-56247EBBF570.dita">Window Server Plugins Component</xref> for more information. </p> </section> <section><title>Render stage plug-ins</title> <p>Render stage plug-ins are designed to allow the customizations of the final stages of the rendering pipeline. The idea is that, to WSERV, a render stage looks pretty much like the graphics context that it is expecting to use to draw to a screen. WSERV carries on with its usual tasks, tracking dirty rectangles and so on, and issuing draw operations when it believes that it needs to repaint some region of the screen. However, instead of these draw operations being used immediately to repaint the screen, they are passed to a render stage. The simplest render stage implementation would indeed use the draw operations to repaint the screen. However, the render stage may do other things with the draw operations, such as capturing some of them for later use in a transition effect or redirecting them to another target and so on. </p> <p>The render stage API is such that every time WSERV wants to do a redraw, it must call <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-75503F6F-91DA-3392-8CD5-34FFF9095D30"><apiname>CWsRenderStage::Begin()</apiname></xref> in order to get hold of the graphics context with which to do the drawing. When it is finished, it must call <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-0EBA06BF-D17F-3485-85B6-F4B855A48B62"><apiname>CWsRenderStage::End()</apiname></xref>, and release its pointer to the graphics context. This means in particular that render stages understand that draw operations come in blocks corresponding to a single redraw. </p> <p>Render stages can be chained, so that the output of the first render stage (in the form of draw operations), passes not to the screen but to a second render stage. In the default implementation supplied with WSERV, two render stages are used to achieve flicker-free drawing. The first render stage takes the draw operations that are passed in, and draws them to an offscreen bitmap. When <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-0EBA06BF-D17F-3485-85B6-F4B855A48B62"><apiname>CWsRenderStage::End()</apiname></xref> is called, it then blits the updated region to the second render stage. The second render stage draws to the screen. This setup therefore eliminates flicker within individual redraws. </p> <p>For information about render stages in ScreenPlay, see <xref href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita">ScreenPlay Render Stages</xref>. </p> </section> <section><title>Key classes</title> <p>All classes belong to <codeph>wsgraphicdrawer.lib</codeph>. </p> <table id="GUID-57A9F34C-D432-51E9-BC55-06E69A29380E"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Class name</entry> <entry>Description</entry> </row> </thead> <tbody><row><entry><p> <xref href="GUID-28DEFD88-3AB5-3F94-9A26-27B240294950.dita"><apiname>CWsPlugin</apiname></xref> </p> </entry> <entry><p>This is the base class that all top-level plug-in objects must derive from. Note that it is an abstract class – in particular it does not provide an implementation of <xref href="GUID-311158DA-BA24-3CF2-8361-EE36F07EED4B.dita"><apiname>ResolveObjectInterface() |
16 </apiname></xref> (inherited from <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref>) – subclasses are expected to do so for themselves. </p> </entry> </row> <row><entry><p> <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref> </p> </entry> <entry><p>This is the interface that fader plug-ins are required to implement. </p> </entry> </row> <row><entry><p> <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref> </p> </entry> <entry><p>This is the interface that render stage factory plug-ins are required to implement. </p> </entry> </row> <row><entry><p> <xref href="GUID-5A22BB23-DF2D-3E1C-9476-A485C878283D.dita"><apiname>MWsWindow</apiname></xref> </p> </entry> <entry><p>This interface represents a window, and provides plug-ins with information about some attributes of windows. Currently, the only way to get hold of an <xref href="GUID-5A22BB23-DF2D-3E1C-9476-A485C878283D.dita"><apiname>MWsWindow</apiname></xref> is from the new <xref href="GUID-46C44F9F-7E2F-3633-B9EC-624058A84F0E.dita"><apiname>TWsCREvent</apiname></xref> <codeph>EWindowClosing</codeph> event. The intended use is for transition engines to discover information about a window that is closing. </p> </entry> </row> <row><entry><p> <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref> </p> </entry> <entry><p>An interface enabling plug-ins to get pointers to other plug-ins, enabling them to use the services of other plug-ins. An example use would be that a platform provider could write a plug-in providing a new interface <xref href="GUID-CE6A3654-AB67-3FBC-B3D5-69C556F773E8.dita"><apiname>MWsBitmapCache</apiname></xref>. They could modify the <codeph>WSINI.INI</codeph> file to ensure that this plug-in was loaded. Then other plug-ins could request the <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref> interface from the <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref>, and then request the <xref href="GUID-CE6A3654-AB67-3FBC-B3D5-69C556F773E8.dita"><apiname>MWsBitmapCache</apiname></xref> interface from <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref>. Thus the purpose of this interface is to enable the use case where one writes plug-ins providing services for the benefit of other plug-ins. </p> </entry> </row> <row><entry><p> <xref href="GUID-112D3118-4983-3BC5-B4E8-0FB219E03295.dita"><apiname>MWsMemoryRelease</apiname></xref> </p> </entry> <entry><p>This is an SPI that enables plug-in objects to assist WSERV in memory management, by freeing memory when requested to do so. </p> </entry> </row> <row><entry><p> <xref href="GUID-C15F47F9-7C13-302B-AD81-FBB288102AAA.dita"><apiname>MWsIniFile</apiname></xref> </p> </entry> <entry><p>An interface enabling plug-ins to read the <codeph>WSINI.INI</codeph> file. </p> </entry> </row> <row><entry><p>New functions in <xref href="GUID-05641B8E-F59A-3353-A196-642ED3CF608D.dita"><apiname>MWsAnimationScheduler</apiname></xref> </p> </entry> <entry><p>WSERV has an animation scheduler which was previously used to schedule CRP animations, and is now also used to schedule deferred redraws. The default scheduler can be replaced by a plug-in, via the call <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita#GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431/GUID-E0B768A5-3CD0-3429-9DA7-0C3F1ABEFE61"><apiname>MWsGraphicDrawerEnvironment::SetCustomAnimationScheduler(MWsAnimationScheduler*)</apiname></xref>. The class <xref href="GUID-05641B8E-F59A-3353-A196-642ED3CF608D.dita"><apiname>MWsAnimationScheduler</apiname></xref> already contained functions relevant to CRP animation, but the WSERV performance improvements add new functions relevant to deferred redraw. </p> </entry> </row> <row><entry><p>New functions in <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref> </p> </entry> <entry><p> <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref> is an existing class. It is an interface provided to all plug-ins, which makes available some generic services. The new functions are primarily for registration/unregistration of event handlers and memory releasers. </p> </entry> </row> <row><entry><p>New functions in <xref href="GUID-46C44F9F-7E2F-3633-B9EC-624058A84F0E.dita"><apiname>TWsCREvent</apiname></xref> </p> </entry> <entry><p> <xref href="GUID-46C44F9F-7E2F-3633-B9EC-624058A84F0E.dita"><apiname>TWsCREvent</apiname></xref> is an existing class. It provides event reporting of some WSERV internals to Content Rendering Plug-ins (and now other plug-ins too). It is typically used by transition effects plug-ins, to provide them with additional information about what is happening inside WSERV. The new functionality is a new event to notify that a window is closing. </p> </entry> </row> </tbody> </tgroup> </table> </section> </conbody><related-links><link href="GUID-139F9E66-830D-5B94-8674-2F90152EBC4A.dita"><linktext>Fader Plug-ins</linktext> </link> <link href="GUID-053BADC7-858B-5D83-8FEE-BFB6C29AFB73.dita"><linktext>Render Stage Plug-ins</linktext> </link> <link href="GUID-434F690E-738A-51DF-80CC-8A6CC067DA6C.dita"><linktext> Miscellaneous Plug-in |
16 </apiname></xref> (inherited from <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref>) – subclasses are expected to do so for themselves. </p> </entry> </row> <row><entry><p> <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref> </p> </entry> <entry><p>This is the interface that fader plug-ins are required to implement. </p> </entry> </row> <row><entry><p> <xref href="GUID-DE3DA8CA-437D-33B8-A747-941810A48897.dita"><apiname>MWsRenderStageFactory</apiname></xref> </p> </entry> <entry><p>This is the interface that render stage factory plug-ins are required to implement. </p> </entry> </row> <row><entry><p> <xref href="GUID-5A22BB23-DF2D-3E1C-9476-A485C878283D.dita"><apiname>MWsWindow</apiname></xref> </p> </entry> <entry><p>This interface represents a window, and provides plug-ins with information about some attributes of windows. Currently, the only way to get hold of an <xref href="GUID-5A22BB23-DF2D-3E1C-9476-A485C878283D.dita"><apiname>MWsWindow</apiname></xref> is from the new <xref href="GUID-46C44F9F-7E2F-3633-B9EC-624058A84F0E.dita"><apiname>TWsCREvent</apiname></xref> <codeph>EWindowClosing</codeph> event. The intended use is for transition engines to discover information about a window that is closing. </p> </entry> </row> <row><entry><p> <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref> </p> </entry> <entry><p>An interface enabling plug-ins to get pointers to other plug-ins, enabling them to use the services of other plug-ins. An example use would be that a platform provider could write a plug-in providing a new interface <xref href="GUID-CE6A3654-AB67-3FBC-B3D5-69C556F773E8.dita"><apiname>MWsBitmapCache</apiname></xref>. They could modify the <codeph>WSINI.INI</codeph> file to ensure that this plug-in was loaded. Then other plug-ins could request the <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref> interface from the <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref>, and then request the <xref href="GUID-CE6A3654-AB67-3FBC-B3D5-69C556F773E8.dita"><apiname>MWsBitmapCache</apiname></xref> interface from <xref href="GUID-17AD82CF-BCC6-3AF9-A791-68F3FFEC5D70.dita"><apiname>MWsPluginManager</apiname></xref>. Thus the purpose of this interface is to enable the use case where one writes plug-ins providing services for the benefit of other plug-ins. </p> </entry> </row> <row><entry><p> <xref href="GUID-112D3118-4983-3BC5-B4E8-0FB219E03295.dita"><apiname>MWsMemoryRelease</apiname></xref> </p> </entry> <entry><p>This is an SPI that enables plug-in objects to assist WSERV in memory management, by freeing memory when requested to do so. </p> </entry> </row> <row><entry><p> <xref href="GUID-C15F47F9-7C13-302B-AD81-FBB288102AAA.dita"><apiname>MWsIniFile</apiname></xref> </p> </entry> <entry><p>An interface enabling plug-ins to read the <codeph>WSINI.INI</codeph> file. </p> </entry> </row> <row><entry><p>New functions in <xref href="GUID-05641B8E-F59A-3353-A196-642ED3CF608D.dita"><apiname>MWsAnimationScheduler</apiname></xref> </p> </entry> <entry><p>WSERV has an animation scheduler which was previously used to schedule CRP animations, and is now also used to schedule deferred redraws. The default scheduler can be replaced by a plug-in, via the call <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita#GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431/GUID-E0B768A5-3CD0-3429-9DA7-0C3F1ABEFE61"><apiname>MWsGraphicDrawerEnvironment::SetCustomAnimationScheduler(MWsAnimationScheduler*)</apiname></xref>. The class <xref href="GUID-05641B8E-F59A-3353-A196-642ED3CF608D.dita"><apiname>MWsAnimationScheduler</apiname></xref> already contained functions relevant to CRP animation, but the WSERV performance improvements add new functions relevant to deferred redraw. </p> </entry> </row> <row><entry><p>New functions in <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref> </p> </entry> <entry><p> <xref href="GUID-ADBFCAEF-8DC6-3B81-B5ED-E2F36645D431.dita"><apiname>MWsGraphicDrawerEnvironment</apiname></xref> is an existing class. It is an interface provided to all plug-ins, which makes available some generic services. The new functions are primarily for registration/unregistration of event handlers and memory releasers. </p> </entry> </row> <row><entry><p>New functions in <xref href="GUID-46C44F9F-7E2F-3633-B9EC-624058A84F0E.dita"><apiname>TWsCREvent</apiname></xref> </p> </entry> <entry><p> <xref href="GUID-46C44F9F-7E2F-3633-B9EC-624058A84F0E.dita"><apiname>TWsCREvent</apiname></xref> is an existing class. It provides event reporting of some WSERV internals to Content Rendering Plug-ins (and now other plug-ins too). It is typically used by transition effects plug-ins, to provide them with additional information about what is happening inside WSERV. The new functionality is a new event to notify that a window is closing. </p> </entry> </row> </tbody> </tgroup> </table> </section> </conbody><related-links><link href="GUID-139F9E66-830D-5B94-8674-2F90152EBC4A.dita"><linktext>Fader Plug-ins</linktext> </link> <link href="GUID-053BADC7-858B-5D83-8FEE-BFB6C29AFB73.dita"><linktext>Render Stage Plug-ins</linktext> </link> <link href="GUID-434F690E-738A-51DF-80CC-8A6CC067DA6C.dita"><linktext> Miscellaneous Plug-in |
17 Interfaces</linktext> </link> <link href="GUID-E7F6DD98-9080-50E9-B071-56247EBBF570.dita"><linktext>Window Server Plugins Component</linktext> </link> <link href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita"><linktext>Render Stages</linktext> </link> <link href="GUID-A40C75A2-59FF-5472-B279-8B5FBFF68794.dita"><linktext> Content Rendering Plug-ins (CRPs)</linktext> </link> </related-links></concept> |
17 Interfaces</linktext> </link> <link href="GUID-E7F6DD98-9080-50E9-B071-56247EBBF570.dita"><linktext>Window Server Plugins Component</linktext> </link> <link href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita"><linktext>Render Stages</linktext> </link> <link href="GUID-A40C75A2-59FF-5472-B279-8B5FBFF68794.dita"><linktext> Content Rendering Plug-ins (CRPs)</linktext> </link> </related-links></concept> |