Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 99
Текст из файла (страница 99)
This is usually done toupdate the current content of the window because the application’smodel has changed – for example, if the user has tapped a key and addedanother character to a word processor document. This is one of the fewsituations in which drawing occurs outside of a redraw in Symbian OS.This is because the drawing is done by the component FORM rather thanthrough the normal framework of a control.Drawing inside a redraw is typically done because an update of thewindow is needed. That is, part of the window’s area has become invalid.WSERV requests a redraw by sending a redraw message to the clientto tell it that a specified window needs redrawing.
The redraw messagealso contains a rectangle, to reduce the area of the window that theclient needs to draw. The rectangle is the bounding rectangle – that is thesmallest rectangle that contains all of the invalid area. The applicationDRAWING TO WINDOWS469calls the functions BeginRedraw() and EndRedraw() on the windowobject to indicate to WSERV when it wants to do a redraw.The BeginRedraw() function has two variants – one that takes arectangle and one that doesn’t; if the one without a rectangle is used,WSERV will take the rectangle to be the whole of the window. The areathat will be drawn by WSERV in response to the draw command is therectangle that was specified in the BeginRedraw() function, intersectedwith the invalid region.
Clearly, if the rectangle specified is greater thanthe rectangle from the redraw event, then this makes no difference to theredraw. If, it is smaller, then the redraw will only be for part of the invalidregion. This will then mean that WSERV must issue another redraw for theremainder of the area that needs drawing. Of course, all this is assumingthat no part of the window is invalidated or covered up between WSERVsignaling that a redraw is needed and the client acting on the redraw.(If this were to happen, the details become more complicated, but thegeneral principles remain the same.)Since, in general, a redraw will only draw to part of the window, it isimportant that the same state of the model (that is, the last drawn content)be reflected in the redraw.
To see why, suppose that an application’smodel changes, but it does not update its window immediately. Then, ifit receives a redraw event before it has done the update, it must draw theprevious state of the model – because if it drew the current state of themodel, part of the window would show the old state while part showedthe new. Cone circumvents this requirement, since it always invalidatesand redraws the area of the whole control. This means that all the pixelswill always be drawn – and so it is safe for the client application to drawthe new state of the model.This section covers redraws from when Symbian OS was first released,until Symbian OS v7.0.
In later releases, we have added two newfeatures that complicate things further. These are flicker-free redrawingand redraw command storing, and I will discuss them after I haveexplained a window property known as ‘‘backup behind’’, which allowsredrawing to be avoided in certain circumstances.11.10.4 Backup behindBackup behind is a property that you can give to any displayable windowas you construct it. It is particularly useful for short-lived windows, suchas dialogs.When such a window first becomes visible, WSERV creates a bitmapand copies into it the part of the screen that will be obscured by thiswindow. Then, when the window is deleted, WSERV doesn’t need toissue redraws to the windows that were covered, but can use the backupbitmap to restore them.This feature is expensive on memory, since it requires a bitmap and aregion.
Thus we limit its use to one window at a time, and say that if a470THE WINDOW SERVERsecond window requests this functionality, then the first window will loseit. It is also worth noting that this feature can fail due to lack of memory.However, it works in simple situations and can be very useful in avoidingthe IPC required by a redraw.11.10.5 Flicker-free redrawingWe introduced this feature in Symbian OS v7.0s.
For it to work, we needat least one full-screen off-screen bitmap (known as the OSB). There willbe one OSB if the keyword ‘‘FLICKERFREEREDRAW’’ is present in theWSINI.INI file, and from Symbian OS v8.0 onwards, there will be twoOSBs if the keyword ‘‘TRANSPARENCY’’ appears in this file.When the OSB exists, WSERV uses it for all redraws. When WSERVreceives the begin redraw command, all the graphics contexts are redirected to draw to the OSB. Then, when the end redraw command isreceived, WSERV copies the content of the off-screen bitmap back to thescreen.The advantage of this is that no pixel will be changed on thescreen more than once, removing the chance of flicker during theredraw.There is one functionality change as a result of drawing in this way.Before we introduced this feature, the content of the window was notchanged in the begin redraw step.
In particular, if a pixel was not drawn,it would remain unchanged. But now, since the whole area that is beingvalidated by the redraw will be copied from the OSB to the screen in theend redraw, even pixels that are not drawn will be copied from the OSB.Since the content of the OSB is undefined, this is obviously undesirable.So, to avoid this problem, we set the area that is being drawn to thebackground color of the window (or white if it doesn’t have one) inthe OSB. However, this has been known to cause problems for somedrawing code, which assumed that the previous screen content was stillthere.11.10.6 Redraw command storingIn Symbian OS v8.0, we added support for transparent windows. Thisfeature requires that WSERV be able to draw the content of windows upondemand. When the client draws a window, WSERV stores the redrawcommands. It does this for all windows, not just windows that might beinvolved with transparency.The advantage of this to the client is that, so long as it doesn’t changethe content of the window, it doesn’t have to redraw that window eachtime part of it becomes invalid – WSERV will just reprocess the commandsthat it has stored.
However, if the content of the window does change,then the client must tell WSERV, so that it can discard the commandsDIRECT SCREEN ACCESS471it has stored. The client can do this by calling Invalidate() on thewindow object for the area that has changed.
It’s worth noting that beforethis feature came along, a client could rely on WSERV issuing a redrawwhen a window was made visible, and use this as a signal to update itscontent.11.11Direct screen accessThis could be described as ‘‘drawing without windows’’, since the drawing commands do not go through WSERV.Before we introduced this feature, clients could create a screen deviceobject and a graphics context object (defined by the BITGDI component – CFbsScreenDevice and CFbsBitGc), and then use the latterto draw to any area of the screen. The problem was that this would writeover any application that happened to be on the screen at the time! So wedesigned the direct screen access (DSA) feature to give a well-behavedapplication a means of drawing directly to the screen using the previouslymentioned classes, but restricting it only to the area in which its windowis visible.
The DSA mechanism allows an application to determine thevisible area of its window and also to receive notification when thatvisible area changes.To do DSA, a client needs to create an instance of CDirectScreenAccess. This class has a very simple interface with only six publicfunctions:static CDirectScreenAccess* NewL(RWsSession& aWs,CWsScreenDevice& aScreenDevice, RWindowBase& aWin,MDirectScreenAccess& aAbort);∼CDirectScreenAccess();void StartL();inline CFbsBitGc* Gc();inline CFbsScreenDevice*& ScreenDevice();inline RRegion* DrawingRegion();The first function constructs the object, and the second destroys it.
The lastthree functions provide the objects that you use to do the drawing. Thegraphics context is already active on the screen, and its clipping region isset to the area that you are allowed to draw to. The last two functions thatI list provide a screen device set to the current color depth of the screenand the region that you are allowed to draw to. This is provided in caseyou ever need to reset the clipping region of the graphics context.The third function, StartL, is the function that you need to call toinform WSERV that you want to start doing DSA.
During this functioncall, the three objects returned by the inline functions will be set up. Afteryou have called this function, you can safely draw to the screen using theprovided graphics context.472THE WINDOW SERVERWhen WSERV detects that the visible area of the window may bechanging, it notifies the client. The client receives this notificationthrough one of the two callback functions that it provided (specifiedin the class MDirectScreenAccess, and passed by the client asthe last parameter to the NewL of the CDirectScreenAccess class).They are:virtual void AbortNow(RDirectScreenAccess::TTerminationReasons aReason)virtual void Restart(RDirectScreenAccess::TTerminationReasons aReason)The first of these functions is called by the DSA framework to tellthe client to abort. When the client has aborted, WSERV must beinformed.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
