diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-139F9E66-830D-5B94-8674-2F90152EBC4A.dita --- a/Symbian3/PDK/Source/GUID-139F9E66-830D-5B94-8674-2F90152EBC4A.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-139F9E66-830D-5B94-8674-2F90152EBC4A.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,17 +1,17 @@ - - - - - -Fader Plug-insThis topic provides information about fader plug-ins in the non-ScreenPlay variant.

Variant: Non-ScreenPlay. Target audience: Device creators.

In ScreenPlay, fading effects can be created using render stages. See ScreenPlay Render Stages for more information.

Purpose

This document is intended to demonstrate how to implement a MWsFader interface for use by plug-ins.

Setup and configuration requirements

All specified plug-ins are loaded by WSERV, or the default plug-ins are loaded if none are specified.

The plug-ins to be loaded are specified in the WSINI.INI file using a line such as the following:

PLUGINS FLICKERBUFFER STD DEFAULTFADER

Each plug-in can then have its own section in the WSINI.INI file in which ID, TYPE, and DATA parameters can be specified. These are as follows:

  • ID is a UID, used to search for <uid>.dll.

  • TYPE is a type, used for every dll of that type. This can be used if no UID is specified.

  • DATA can be used to pass arbitrary data to a plug-in.

A typical section might look like this:

[FLICKERBUFFER] -ID 0x10285A2C
Using fader plug-ins

The high level steps for loading and using fader plug-ins are:

  1. Screen gets pointer to fader object at construction time

  2. Fader is called to perform custom fading of screen region

1. Screen gets pointer to fader object at construction - time

Setup in WSINI.INI file

In the WSINI.INI file, the name of the fader to be used is specified on a per screen basis using lines such as the following:

[SCREEN 0]

FADER DEFAULTFADER

If no fader is specified, the default fader will be used.

Process

The following code will need to be used:

CScreen::ConstructL() is called.

WsIniFile()->FindVar(“FADER”) will return the name of fader to be used

CWsPluginManager::FindNamedImplementation<MwsFader>() is called. This is a templated function, where the template determines what is returned.

For each plug-in in the list of plug-ins:

  • Call CWsPlugin::ObjectInterface(“MWsFader”), requesting the plug-in to supply the MWsFader interface

  • This results in a call to ResolveObjectInterface(“MWsFader”) on the plug-in. If the plug-in is a fader plug-in, then it is required to “return this ”, otherwise “return NULL

  • If the plug-in returns an MWsFader*, and it has the correct plug-in name, return the MWsFader*

Endfor.

2. Fader is called to perform custom fading of screen - region

Process

CWsWindowRedraw::PostDrawWindow() is called

If fading enabled: Get the pointer to the fader instance via CPlaybackGc

  • Call CFader::SetFadingParameters().

  • Call CFader::FadeArea()

  • The fader plug-in fades the requested area.

Endif.

Window Server Plug-in Framework in the - Non-ScreenPlay Variant Render Stage Plug-ins Miscellaneous Plug-in + + + + + +Fader Plug-insThis topic provides information about fader plug-ins in the non-ScreenPlay variant.

Variant: Non-ScreenPlay. Target audience: Device creators.

In ScreenPlay, fading effects can be created using render stages. See ScreenPlay Render Stages for more information.

Purpose

This document is intended to demonstrate how to implement a MWsFader interface for use by plug-ins.

Setup and configuration requirements

All specified plug-ins are loaded by WSERV, or the default plug-ins are loaded if none are specified.

The plug-ins to be loaded are specified in the WSINI.INI file using a line such as the following:

PLUGINS FLICKERBUFFER STD DEFAULTFADER

Each plug-in can then have its own section in the WSINI.INI file in which ID, TYPE, and DATA parameters can be specified. These are as follows:

  • ID is a UID, used to search for <uid>.dll.

  • TYPE is a type, used for every dll of that type. This can be used if no UID is specified.

  • DATA can be used to pass arbitrary data to a plug-in.

A typical section might look like this:

[FLICKERBUFFER] +ID 0x10285A2C
Using fader plug-ins

The high level steps for loading and using fader plug-ins are:

  1. Screen gets pointer to fader object at construction time

  2. Fader is called to perform custom fading of screen region

1. Screen gets pointer to fader object at construction + time

Setup in WSINI.INI file

In the WSINI.INI file, the name of the fader to be used is specified on a per screen basis using lines such as the following:

[SCREEN 0]

FADER DEFAULTFADER

If no fader is specified, the default fader will be used.

Process

The following code will need to be used:

CScreen::ConstructL() is called.

WsIniFile()->FindVar(“FADER”) will return the name of fader to be used

CWsPluginManager::FindNamedImplementation<MwsFader>() is called. This is a templated function, where the template determines what is returned.

For each plug-in in the list of plug-ins:

  • Call CWsPlugin::ObjectInterface(“MWsFader”), requesting the plug-in to supply the MWsFader interface

  • This results in a call to ResolveObjectInterface(“MWsFader”) on the plug-in. If the plug-in is a fader plug-in, then it is required to “return this ”, otherwise “return NULL

  • If the plug-in returns an MWsFader*, and it has the correct plug-in name, return the MWsFader*

Endfor.

2. Fader is called to perform custom fading of screen + region

Process

CWsWindowRedraw::PostDrawWindow() is called

If fading enabled: Get the pointer to the fader instance via CPlaybackGc

  • Call CFader::SetFadingParameters().

  • Call CFader::FadeArea()

  • The fader plug-in fades the requested area.

Endif.

Window Server Plug-in Framework in the + Non-ScreenPlay Variant Render Stage Plug-ins Miscellaneous Plug-in Interfaces
\ No newline at end of file