7 Nokia Corporation - initial contribution. |
7 Nokia Corporation - initial contribution. |
8 Contributors: |
8 Contributors: |
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 id="GUID-894AB487-C127-532D-852B-37CB0DEA1440" xml:lang="en"><title>Symbian-Specific |
12 <concept id="GUID-894AB487-C127-532D-852B-37CB0DEA1440" xml:lang="en"><title>Symbian-Specific Behavior</title><shortdesc>This topic provides information about the points that the |
13 Behavior</title><shortdesc>This topic provides information about the points that the EGL specification |
13 EGL specification explicitly states are platform-specific. This information |
14 explicitly states are platform-specific. This information is aimed at both |
14 is aimed at both users and implementers of EGL on the Symbian platform. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
15 users and implementers of EGL on the Symbian platform. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
15 <section id="GUID-E6A596AC-1BCE-4B99-89CF-67EE28A45068"><title>ScreenPlay |
16 <section id="GUID-5F4317DF-EEDE-434C-906D-A354367AE38D"><title>Symbian windows</title> <p>EGL |
16 (NGA)</title><p>Applications can find out whether ScreenPlay (also |
17 window surfaces are tied to Symbian windows. To create an on-screen rendering |
17 known as the New Graphics Architecture or NGA) is supported on the |
18 surface, a Window Server window with attributes corresponding to the desired <codeph>EGLConfig</codeph> must |
18 device at runtime. </p><p>To do this, call <codeph>eglQueryString(display, |
19 be created first. The <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> class is a handle to a server-side |
19 EGL_EXTENSIONS)</codeph> and search for the string <codeph>EGL_SYMBIAN_COMPOSITION</codeph> within the string returned. If <codeph>EGL_SYMBIAN_COMPOSITION</codeph> is present, it means that ScreenPlay is supported. For further information, |
20 window that can be displayed and drawn to, and whose redraws are performed |
20 see <xref href="GUID-2923A42C-1C0E-553D-8563-7B9FC51F153F.dita">EGL Functions |
21 by the application. </p> <p><b>Threading</b>. Because of the limitations of |
21 with Symbian-Specific Behavior</xref>.</p><p>By checking for the presence |
22 the Window Server API, clients <b>must</b> create and use an EGL window surface |
22 of the <codeph>EGL_SYMBIAN_COMPOSITION</codeph> string, you can create |
23 in the thread in which its <codeph>RWindow</codeph> was created. This means |
23 applications that can work on both ScreenPlay devices and those with |
24 that the following are <b>not</b> supported and will lead to undefined behavior:</p><ul> |
24 the non-ScreenPlay architecture.</p></section> |
25 <li><p>Creating an EGL window surface in thread <i>B</i> using an <codeph>RWindow</codeph> that |
25 <section id="GUID-5F4317DF-EEDE-434C-906D-A354367AE38D"><title>Symbian |
26 was created in thread <i>A</i>. </p></li> |
26 windows</title> <p>EGL window surfaces are on-screen rendering surfaces |
27 <li><p>Using an EGL window surface in thread <i>B</i> when that EGL window |
27 that are tied to Symbian windows. The <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> class |
28 surface and its <codeph>RWindow</codeph> were created in thread <i>A</i>. </p></li> |
28 is a client-side handle to a Symbian Window Server window. You must |
29 </ul><p>For example, in the second scenario, EGL in thread <i>B</i> may fail |
29 create the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> before creating the EGL window |
30 when it attempts to get the window size from the <codeph>RWindow</codeph> in |
30 surface for on-screen rendering.</p><p>Because the EGL window surface |
31 thread <i>A</i>.</p><p><b>Buffer handling</b>. EGL window surfaces have two |
31 is implemented differently depending on whether ScreenPlay is in use, |
32 buffers, known as the front and back buffers. This means that the client application |
32 there are some differences in how you create an EGL window surface:</p><ul> |
33 can draw to the back buffer, while the front buffer is being composed to the |
33 <li><p>In ScreenPlay, the pixel format of the EGL window surface is |
34 screen. The client must call <codeph>eglSwapBuffers()</codeph> to post the |
34 determined entirely by the EGL config passed to <codeph>eglCreateWindowSurface()</codeph> and not by the properties of the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref>.</p></li> |
35 back buffer to the screen. </p><p>EGL 1.4 introduces a preserve buffer feature. |
35 <li><p>On a non-ScreenPlay device, the display mode of the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> must match the buffer size of the EGL window surface. |
36 When this is supported by the implementation, the content of the buffer can |
36 You can call <xref href="GUID-1460DD8F-9AA1-3B99-8FFD-F309959CCA34.dita#GUID-1460DD8F-9AA1-3B99-8FFD-F309959CCA34/GUID-FE6998EA-7B17-3270-B487-04D98EBB8424"><apiname>RWindowBase::DisplayMode() const</apiname></xref> to |
37 be preserved from one frame to the next. This means that the client can provide |
37 retrieve the window’s display mode and use it to determine the buffer |
38 incremental drawing operations rather than the entire drawing operations for |
38 size when retrieving the EGL config to pass to <codeph>eglCreateWindowSurface()</codeph>. </p></li> |
39 each frame. When the implementation supports this feature, it is usually off |
39 </ul> <p><b>Threading</b>. Because of the limitations of the Window |
40 by default. This means that legacy applications that do not expect |
40 Server API, clients <b>must</b> create and use an EGL window surface |
41 this feature are not slowed down by the unnecessary copying of the buffer |
41 in the thread in which its <codeph>RWindow</codeph> was created. This |
42 contents.</p> <p><b>Window resizing</b>. A window can be resized using one |
42 means that the following are <b>not</b> supported and will lead to |
43 of the Window Server or UI Framework APIs, such as <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-BCD76117-54A3-3CD5-8911-E867512BF85B"><apiname>RWindow::SetExtent()</apiname></xref> or <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-B680C675-2146-3162-AAAC-F3E88FA8B045"><apiname>CCoeControl::SetExtent()</apiname></xref>. |
43 undefined behavior:</p><ul> |
44 When these APIs are called on a window that is bound to an EGL window surface, |
44 <li><p>Creating an EGL window surface in thread <i>B</i> using an <codeph>RWindow</codeph> that was created in thread <i>A</i>. </p></li> |
45 the EGL implementation is expected to handle the situation by adjusting its |
45 <li><p>Using an EGL window surface in thread <i>B</i> when that EGL |
46 internal buffers. Applications need not do anything specific with regard to |
46 window surface and its <codeph>RWindow</codeph> were created in thread <i>A</i>. </p></li> |
47 EGL APIs. Depending on the type of application, APIs may want to adjust their |
47 </ul><p>For example, in the second scenario, EGL in thread <i>B</i> will fail (with a WSERV panic) when it attempts to get the window |
48 rendering operations—for example, clip or scale the contents. </p> <p>EGL |
48 size from the <codeph>RWindow</codeph> in thread <i>A</i>.</p><p><b>Buffer handling</b>. By default EGL window surfaces have multiple |
49 handles the resize in the next call to <codeph>eglSwapBuffers()</codeph> by |
49 buffers, which means that the client can draw to a back buffer, while |
50 creating a new surface for the resized window. If the preserve buffer option |
50 the front buffer is being composed to the screen. The client must |
51 is in use, this function also copies across all the pixels from the old surface |
51 call <codeph>eglSwapBuffers()</codeph> to post the back buffer to |
52 that overlap the new surface, although the exact details depend on the implementation. |
52 the screen.</p><p> EGL 1.4 introduces a preserve buffer feature, which |
53 A client application may therefore need to provide extra drawing operations, |
53 enables the content of the front buffer to be preserved from one frame |
54 for example, if the window is made larger.</p> <p> <b>Screen rotation</b>. |
54 to the next. This means that the client can provide incremental drawing |
55 There is no specific EGL handling for screen rotation—instead screen rotation |
55 operations rather than the entire drawing operations for each frame. |
56 is handled in the same way as a change of screen resolution. Applications |
56 This feature is usually off by default. This means that legacy applications |
57 can detect screen rotation by listening to the Window Server event <xref href="GUID-CC1E6B2E-F68F-3A00-B4EA-4917007F7320.dita"><apiname>EEventScreenDeviceChanged</apiname></xref>. |
57 that do not expect this feature are not slowed down by the unnecessary |
58 However, applications do not normally use the Window Server API directly, |
58 copying of the buffer contents.</p> <p><b>Window resizing</b>. The |
59 because they are built on top of the UI Framework layer. This layer provides |
59 size of an application’s view can be changed by a variety of external |
60 a different mechanism to notify applications using—for example, <xref href="GUID-3AC2CDAC-0291-309F-A020-049BC9F2CF90.dita#GUID-3AC2CDAC-0291-309F-A020-049BC9F2CF90/GUID-5723655E-FC84-35F1-A0E1-FCE92CEBC196"><apiname>CCoeAppUi::HandleScreenDeviceChangedL()</apiname></xref>. </p> <p>When |
60 events, such as a UI layout switch, a change in the size of the status |
61 one of the these events is detected, the application may need to resize its |
61 pane or the rotation of the screen. An application can also resize |
62 windows and update its content accordingly. If the application wants to accept |
62 a window directly, such as through a call to <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-BCD76117-54A3-3CD5-8911-E867512BF85B"><apiname>RWindow::SetExtent()</apiname></xref>, <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-B680C675-2146-3162-AAAC-F3E88FA8B045"><apiname>CCoeControl::SetExtent()</apiname></xref> or <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-5A63E1BD-BCCA-356E-BB39-D4BB7B6DC22E"><apiname>CCoeControl::SetExtentToWholeScreen()</apiname></xref>.</p><p>When there is a change in the size of a window that is bound |
63 the system rotation, it does not need to rotate its content. However, some |
63 to an EGL window surface, the application must take appropriate action |
64 applications may want to maintain a fixed physical orientation. They would |
64 in its <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-FFF07CE8-61C4-34F9-B9E9-D315782C8476"><apiname>CCoeControl::SizeChanged(</apiname></xref>) or <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-1BC64D91-2796-3F16-AA41-13836BC00701"><apiname>CCoeControl::HandleResourceChange()</apiname></xref> implementation. The action depends on the nature of the application |
65 then need to rotate the window content in order to counteract the physical |
65 but might include clipping or scaling the contents to fit the resized |
66 rotation. </p> </section> |
66 window.</p><p>On the Symbian platform, EGL handles the window resize |
67 <section id="GUID-9BC770D9-3736-495E-8485-19D71700C50D"><title>Symbian pixmap |
67 in the next call to <codeph>eglSwapBuffers()</codeph>, which resizes |
68 types</title> <p>An EGL implementation can support the <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> pointer |
68 the surface to match the new window size. If the preserve buffer option |
69 as an <codeph>EGLNativePixmapType</codeph>. This means that it is possible |
69 is in use, this function also copies across all the pixels from the |
70 to create an <codeph>EGLSurface</codeph> to render to a <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref>. </p> <p> <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> bitmaps |
70 old surface that overlap the new surface, although the exact details |
71 are managed by the <xref href="GUID-71DADA82-3ABC-52D2-8360-33FAEB2E5DE9.dita">Font |
71 depend on the implementation.</p><p>If the surface resize fails, <codeph>eglSwapBuffers()</codeph> returns <codeph>EGL_FALSE</codeph> and |
72 and Bitmap Server</xref>. The format is internal to Symbian, but the Image |
72 an <codeph>EGL_BAD_ALLOC</codeph> error is raised. This may mean that |
73 Converter API can be used to convert them to standard formats. The <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> type |
73 the implementation does not support the resizing of a surface or that |
74 has limitations with regard to hardware acceleration. </p> </section> |
74 there is not enough memory available (on a platform with GPU, this |
75 <section id="GUID-44553B50-C48E-4E6B-AD9C-F3BC7D9D5347"><title>Display handling</title> <p>Most |
75 would be GPU rather than system memory). Applications must always |
76 EGL calls include an <codeph>EGLDisplay</codeph> parameter. The EGL specification |
76 monitor whether <xref href="GUID-7F4F23A8-26FA-33E5-87DA-4EE1D3DC65AE.dita"><apiname>eglSwapBuffers()</apiname></xref> fails after a |
77 describes this as "the abstract display on which graphics are drawn". On some |
77 window resize. When it does fail, the application should do the following:</p><ol> |
78 systems, this corresponds to a physical screen. However, the details are platform |
78 <li id="GUID-81762FDD-72AD-410E-8E18-FFFF75CF6A32"><p>Call <codeph>eglDestroySurface()</codeph> to destroy the current EGL window surface.</p></li> |
79 specific and on Symbian systems, it does <i>not</i> correspond to a physical |
79 <li id="GUID-79FFA30C-1F31-47C0-9084-F72FF0E57FC6"><p>Call <codeph>eglCreateWindowSurface()</codeph> to recreate the EGL window surface.</p></li> |
80 screen. When working on the Symbian platform, it is generally more useful |
80 </ol> <p>This may cause a noticeable flicker and so should be done |
81 to think of an <codeph>EGLDisplay</codeph> as the EGL session. </p> <p>On |
81 only when necessary.</p><p> <b>Screen rotation</b>. There is no specific |
82 Symbian systems, you usually use a single <codeph>EGLDisplay</codeph>. You |
82 EGL handling for screen rotation—instead screen rotation is handled |
83 get this by a call to <codeph>eglGetDisplay()</codeph> and passing <codeph>EGL_DEFAULT_DISPLAY</codeph> as |
83 in the same way as a change of screen resolution. An application typically |
84 the <codeph><display id></codeph> parameter. </p> <p>The physical screen |
84 handles changes in screen resolution and rotation in its <xref href="GUID-3AC2CDAC-0291-309F-A020-049BC9F2CF90.dita#GUID-3AC2CDAC-0291-309F-A020-049BC9F2CF90/GUID-5723655E-FC84-35F1-A0E1-FCE92CEBC196"><apiname>CCoeAppUi::HandleScreenDeviceChangedL()</apiname></xref> or <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-A925DD23-4531-3BA5-AF17-E6289F9E370A"><apiname>CCoeControl::HandleResourceChange(TInt)</apiname></xref> implementation. When there is a change in screen rotation, the application |
85 on which the content is displayed is determined by the window's parent window |
85 may need to resize its windows and update the content accordingly. </p> <p>The EGL implementation updates the surface size on the next call |
86 group. In Symbian, every window (<xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref>) has a parent |
86 to <codeph>eglSwapBuffers()</codeph>. However, the interim frames |
87 window group (<xref href="GUID-64D4D428-D65F-3D9D-A0D4-C8338C848B25.dita"><apiname>RWindowGroup</apiname></xref>), as shown in the following |
87 appear in the new orientation, and so an application may want to adjust |
88 diagram. When you create a window group, you can specify the screen on which |
88 the contents to minimize flicker. If the application wants to accept |
89 it is to be shown. </p> <fig id="GUID-5D5F3C6A-4CFA-5307-8B2D-D2881799D664"> |
89 the system rotation, it does not need to rotate its content. However, |
90 <title>Each window has a parent window group which is associated with a screen</title> |
90 some applications may require a fixed physical orientation. These |
91 <image href="GUID-CF9EF400-DE1F-55F7-BD33-C4CD80462971_d0e211044_href.png" placement="inline"/> |
91 need to rotate the window content in order to counteract the physical |
92 </fig> <p>When you create a window surface in EGL using <codeph>eglCreateWindowSurface</codeph>, |
92 rotation. </p><p>Sometimes a screen rotation simply results in the |
93 you pass in the <codeph>RWindow</codeph> as an argument. The window surface |
93 swapping of the window’s width and height dimensions—for example, |
94 is then displayed on the screen associated with that window's parent window |
94 when the application is running in full screen mode and the device |
95 group. Currently a window can exist on only one screen. </p> </section> |
95 is rotated from portrait to landscape or vice versa. This is guaranteed |
|
96 to succeed on all Symbian EGL implementations.</p><p>In other situations |
|
97 the screen rotation must be treated like a window resize and the application |
|
98 must monitor whether <codeph>eglSwapBuffers()</codeph> succeeds and |
|
99 take appropriate action if it fails, as described above. For example, |
|
100 if the application is not in full screen mode, rotating the device |
|
101 from portrait to landscape may not result in the swapping of the width |
|
102 and height of the window.</p> <p><b>UI content</b>. Applications that |
|
103 want to make use of the ScreenPlay ability to place semi-transparent <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> rendering above the EGL window surface should |
|
104 check whether ScreenPlay is supported on the device as described above. </p><p>On ScreenPlay devices, you can combine <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> drawing and OpenVG/OpenGL ES drawing in the same window, provided |
|
105 the <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> content is drawn using a semi-transparent |
|
106 pen or brush color or bitmap. It is also possible to create semi-transparent <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> drawing in another Symbian window placed over |
|
107 the EGL window. To do this, make the Symbian window semi-transparent |
|
108 by calling <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-47275C08-0C58-3A03-B96F-38F881F49C08"><apiname>RWindow::SetTransparencyAlphaChannel()</apiname></xref>. <xref href="GUID-02BD38E7-A579-5BD5-9444-4E7C14C7809A.dita">Transparent |
|
109 Windows</xref> has more detail on implementing semi-transparent windows.</p><p>On non-ScreenPlay devices, you need to place the <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> drawing in an opaque child window over the EGL window surface or |
|
110 implement the UI by using OpenVG/OpenGL ES drawing that is directed |
|
111 to the EGL window surface itself.</p><p><b>Window lifetime</b>. Clients |
|
112 must maintain the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> associated with the EGL |
|
113 window surface for the lifetime of that window surface, provided they |
|
114 follow the good practice guidelines of unbinding the EGL window surface |
|
115 from the current context before destroying it. If these guidelines |
|
116 are not followed, it may be necessary to maintain the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> for the entire duration of EGL usage within the client application.</p><p>For example, the following pseudocode demonstrates good practice. |
|
117 The <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> must be valid until <codeph>eglDestroySurface()</codeph> is called:</p><codeblock xml:space="preserve">// Unbind the window surface from the current context. |
|
118 eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT); |
|
119 |
|
120 // Destroy the window surface. |
|
121 eglDestroySurface(display, surface); |
|
122 |
|
123 ... |
|
124 |
|
125 eglTerminate(display)</codeblock><p>When the application does not |
|
126 follow this good practice and destroys the surface before unbinding |
|
127 it from the current context, the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> must be |
|
128 valid for longer. For example in the following pseudocode, <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> must be valid until after <codeph>eglMakeCurrent()</codeph> is called:</p><codeblock xml:space="preserve">eglDestroySurface(display, surface); |
|
129 eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT); |
|
130 |
|
131 ... |
|
132 |
|
133 eglTerminate(display)</codeblock><p>If <xref href="GUID-2095B4FC-106B-3839-9EE1-9F6B5E8C47B6.dita"><apiname>eglMakeCurrent(</apiname></xref>) is not called with a null surface and null context at all, the <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> must be valid until <codeph>eglTerminate()</codeph> is called.</p> </section> |
|
134 <section id="GUID-9BC770D9-3736-495E-8485-19D71700C50D"><title>Symbian |
|
135 pixmap types</title> <p>An EGL implementation can support the <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> pointer as an <codeph>EGLNativePixmapType</codeph>. This means that it is possible to create an <codeph>EGLSurface</codeph> to render to a <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref>. However, it is not |
|
136 guaranteed to be supported on all EGL implementations.</p> </section> |
|
137 <section id="GUID-44553B50-C48E-4E6B-AD9C-F3BC7D9D5347"><title>Display |
|
138 handling</title> <p>Most EGL calls include an <codeph>EGLDisplay</codeph> parameter. The EGL specification describes this as "the abstract |
|
139 display on which graphics are drawn". On some systems, this corresponds |
|
140 to a physical screen. However, the details are platform specific and |
|
141 on Symbian systems, it does <i>not</i> correspond to a physical screen. |
|
142 When working on the Symbian platform, it is generally more useful |
|
143 to think of an <codeph>EGLDisplay</codeph> as the EGL session. </p> <p>On Symbian systems, you usually use a single <codeph>EGLDisplay</codeph>. You get this by a call to <codeph>eglGetDisplay()</codeph> and |
|
144 passing <codeph>EGL_DEFAULT_DISPLAY</codeph> as the <codeph><display |
|
145 id></codeph> parameter. </p> <p>The physical screen on which the content |
|
146 is displayed is determined by the window's parent window group. In |
|
147 Symbian, every window (<xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref>) has a parent window |
|
148 group (<xref href="GUID-64D4D428-D65F-3D9D-A0D4-C8338C848B25.dita"><apiname>RWindowGroup</apiname></xref>), as shown in the following |
|
149 diagram. When you create a window group, you can specify the screen |
|
150 on which it is to be shown. </p> <fig id="GUID-5D5F3C6A-4CFA-5307-8B2D-D2881799D664"> |
|
151 <title>Each window has a parent window group which is associated with |
|
152 a screen</title> |
|
153 <image href="GUID-CF9EF400-DE1F-55F7-BD33-C4CD80462971_d0e206241_href.png" placement="inline"/> |
|
154 </fig> <p>When you create a window surface in EGL using <codeph>eglCreateWindowSurface</codeph>, you pass in the <codeph>RWindow</codeph> as an argument. The window |
|
155 surface is then displayed on the screen associated with that window's |
|
156 parent window group. Currently a window can exist on only one screen. </p> </section> |
96 </conbody><related-links> |
157 </conbody><related-links> |
97 <link href="GUID-D252E75C-C8CA-5C51-8DA3-95B937A1295C.dita"><linktext>EGL Interface |
158 <link href="GUID-D252E75C-C8CA-5C51-8DA3-95B937A1295C.dita"><linktext>EGL |
98 Component</linktext></link> |
159 Interface Component</linktext></link> |
99 <link href="GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita"><linktext>EGL Collection |
160 <link href="GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita"><linktext>EGL |
100 Overview</linktext></link> |
161 Collection Overview</linktext></link> |
|
162 <link href="GUID-53707903-9A88-409B-80F8-FDF7EF47ACBF.dita"><linktext>Coverflow: |
|
163 using ScreenPlay</linktext></link> |
|
164 <link href="GUID-484B51EC-2209-5492-8E9C-9D792AB0DF35.dita"><linktext>Drawing |
|
165 with CWindowGc</linktext></link> |
101 </related-links></concept> |
166 </related-links></concept> |