Week 23 contribution of PDK documentation content. See release notes for details. Fixes bugs Bug 2714, Bug 462.
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License
"Eclipse Public License v1.0" which accompanies this distribution,
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
Nokia Corporation - initial contribution.
Contributors:
-->
<!DOCTYPE concept
PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-C6E9D609-E82C-4FAC-9265-F6A4FF61049C" xml:lang="en"><title>Drawing
in the view architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The Symbian platform calls <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> when
a control area needs to be updated on the display. Controls may implement <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> or
leave the drawing to their child controls. For more information on control
hierarchies, see <xref href="GUID-E244744F-4837-5B46-8E37-4666A28BF0B7.dita">The
run-time control hierarchy</xref>. </p>
<p>The Symbian platform calls <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> for
the parent control first, and then recursively for each control.</p>
<p>Controls should override <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> to draw
their content. The override should do nothing else and should be as fast as
possible. For example, it is bad design to create fonts dynamically, and read
any bitmaps or resources while drawing. A good rule of thumb is that there
should not be trap handlers in the method override; any time-consuming functionality
that can be done beforehand should be cached.</p>
<p>In most cases controls are drawn on the display using the screen device
graphics context, accessed with <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-6586DB74-AF5C-330B-9D0A-E4637396A04E"><apiname>CCoeControl::SystemGc()</apiname></xref>.
The graphics context provides a wide set of <xref href="GUID-E89F034F-C807-5FF9-B06B-F7CCD2441041.dita">GDI</xref> (Graphics
Device Interface - common Symbian platform graphics API) drawing primitives
that can be used for drawing virtually anything on screen.</p>
<p>An example of a basic override of <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> for
a control that is a top-level window in an application is as follows:</p>
<codeblock id="GUID-9EF298F3-9B92-48C1-BA7C-0C91143D075C" xml:space="preserve">void CMyAppView::Draw( const TRect& /*aRect*/ ) const
{
// Get the standard graphics context
CWindowGc& gc = SystemGc();
gc.SetPenStyle( CGraphicsContext::ENullPen );
gc.SetBrushColor( KRgbWhite);
gc.SetBrushStyle( CGraphicsContext::ESolidBrush );
// Gets the control's extent
TRect rect( Rect());
{
gc.Clear( rect );
}
}
</codeblock>
<p>, where</p>
<ul>
<li><p><parmname>CWindowGc& gc = SystemGc();</parmname> gets
the graphics context that is used when drawing the control.</p></li>
<li><p><xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-026A1015-0D79-3A66-91BA-5FB343387EE0"><apiname>CWindowGc::SetPenStyle()</apiname></xref>, <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-0A923CAA-7A89-3ED2-A844-2F4147B62FEC"><apiname>CWindowGc::SetBrushColor()</apiname></xref>,
and <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-363A9FB3-75F7-3EB7-A783-91BBAEBCE670"><apiname>CWindowGc::SetBrushStyle()</apiname></xref> are used to set the drawing
primatives for the context.</p></li>
<li><p><xref href="GUID-101762DC-E498-3325-88AB-B0FF17DC62B6.dita"><apiname>TRect</apiname></xref> gets the size of the control rectangle.</p>
</li>
<li><p><xref href="GUID-D22FD07E-59E0-346A-9BFA-8D109F509DB1.dita"><apiname>CWindowGc:Clear(rect)</apiname></xref> clears the control
rectangle.</p></li>
</ul>
<section id="GUID-DBACBFCC-F260-4ABE-B55C-BBB23F332E42"><title>Drawing with
caches</title>
<p>For controls that perform intensive drawing operations, the drawing
should be cached: a process also known as double-buffering. Here the drawing
is done to a memory context first and then in the <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> method
only the context's bitmap is passed to screen. In the Symbian platform, the
easiest way to implement a double buffer is to create a <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> and
then bind a graphics context to that - this makes it possible to use the
same GDI interface for drawing as the display context. The drawing is done
to a memory bitmap buffer, and when the Symbian platform updates the invalidated
screen area, the memory buffer is copied to it. Double-buffering is a common
paradigm used in games, but can also be utilized in any application when performance
of drawing controls is important.</p>
<p>The following is a short example of how a double buffer is created and
used:</p>
<codeblock id="GUID-995DBACE-EE60-4666-BDCF-975EE98B01FD" xml:space="preserve">iGcBmp = new (ELeave) CWsBitmap(iEikonEnv->WsSession());
User::LeaveIfError(iGcBmp->Create(aClientRect.Size(), iEikonEnv->ScreenDevice()->DisplayMode()));
iGcDevice = CFbsBitmapDevice::NewL(iGcBmp);
User::LeaveIfError(iGcDevice->CreateBitmapContext(iGc));
</codeblock>
<p><parmname>iGcBmp</parmname> is a pointer to <xref href="GUID-17150D76-BB82-3A4B-8B1A-8BA93CB1A9EF.dita"><apiname>CWsBitmap</apiname></xref>,
the bitmap memory buffer, that is created with the same width and height as
the top-level window and with the same color bit depth as the display.<parmname> iGcDevice</parmname> is
a pointer to the <xref href="GUID-2DEFEC47-F36E-3133-A08D-55F7C2534CC0.dita"><apiname>CBitmapDevice</apiname></xref> device class and the context <parmname>iGc</parmname> holds
the <xref href="GUID-FC746873-0570-3900-AD89-42B205FDC0D3.dita"><apiname>CBitmapContext</apiname></xref> instance. <parmname>iGc</parmname> is
then used instead of <parmname>CScreenGc</parmname>, obtained from the <parmname>CCoeControl::SystemGc()</parmname> method,
when the control draws itself. The double-buffer drawing should be done outside
of the <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-63295719-90A0-3D53-A643-0C52BF4068A1"><apiname>CCoeControl::Draw()</apiname></xref> method and can be called directly
when needed. Only at the end of the off-screen drawing is the memory buffer
flushed to the screen by calling <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-9FB682AC-0209-302A-83F3-7BCB1162B998"><apiname>CCoeControl::DrawDeferred()</apiname></xref></p>
<codeblock id="GUID-13A1E553-7A78-422C-85AC-7C89696B2D18" xml:space="preserve">void CMyDrawingExample::Draw(const TRect& /*aRect*/) const
{
SystemGc().BitBlt(TPoint(0, 0), iGcBmp);
}</codeblock>
</section>
</conbody></concept>