Site Design Change
If this is your first visit to Ayrware in a while, you can’t fail to notice that the site’s ‘look and feel’ has changed significantly. The main reason for the re-design was simply to make the site’s content more accessible and, in the process, increase the time visitors spend on the site.
Looking at the Analytics data for May of this year, you can see that the average length of visit was one minute and nineteen seconds.
Even though this figure is 452% higher than the benchmark, it was deemed that the ‘old school’ design of the site was not encouraging visitors to linger (the site’s bounce rate was ~73% for May).
Of course, the nature and quality of a site’s content contributes greatly to visit lengths. We hope that by using Wordpress to manage the content and the layout of the site, we can encourage visitors to stay longer and visit more regularly in the future.
GDI+ Double Buffering in MFC’s CView Class
My earlier article on GDI+ double buffering was very much an introduction to the subject, detailing how to declare and use several GDI+ objects important to the technique. This article goes a bit further by describing a more concrete example of double buffering.
Before continuing, I should mention that the code (see downloads page) associated with this article is supplied as an example of how double buffering could be implemented in your project – this code has been extracted from a working project but has been simplified for clarity and will not compile without modification.
Part of the project mentioned above involved development of a small ‘paint’ style package. This was integrated into the main application as an MFC CView derived class which would be responsible for rendering all content in the client area; the user would typically draw and move shapes on screen using the mouse. Although the graphics were going to be very simple, it was perceived that double buffering would be required from the outset.
To facilitate this, GDI+ Bitmap and CachedBitmap pointers were added as member variables to the example CView class. Also, two GDI+ Graphics object pointers were added – one for drawing in the background buffer(Bitmap) and the other for rendering the output in the client area. The class header should look something like the example below.
class CDesignView : public CView
{
DECLARE_DYNCREATE(CDesignView)
public:
...
private:
CachedBitmap* m_pCachedBackground;
Bitmap* m_pBackgroundBMap;
Graphics* m_pBackCanvas;
Graphics* m_pOutputCanvas;
}
The CachedBitmap object would be used in the main CView drawing function, as detailed below.
void CDesignView::OnDraw(CDC* /*pDC*/)
{
if((m_pOutputCanvas != NULL) && (m_pCachedBackground != NULL))
{
m_pOutputCanvas->DrawCachedBitmap(m_pCachedBackground, 0, 0);
}
}
The idea here is that when new content is added to the view by the user, the cached bitmap will be updated to reflect the change. When the client area needs later to be refreshed, the OnDraw function simply renders the cached bitmap, filling the visible client area. This represents a big performance increase over drawing all CView contents individually.
Read the rest of this entry »
GDI+ Double Buffering
GDI+ has been about for a while now and, from a developer’s perspective, is an improvement over the old GDI API. It not only simplifies application development, via it’s class based organisation, but allows some quite startling graphical and textual effects to be used.
Although GDI+ is not hardware accelerated, the performance of this API is acceptable, if you bear in mind that it was never intended to be used for game or animation development. Applications which do need to render complex scenes or move a large number of objects about would have to use OpenGL or DirectX, which are both hardware assisted.
If you are using GDI+, there are a couple of ways you can (must) boost the apparent performance of your application – they are respectively double buffering and use of a cached bitmap. Details of these two techniques are presented below.
How does double buffering work then? Well, to put it simply, an off-screen buffer is created of the same dimensions as the output screen or window. All drawing operations are targeted at this buffer using standard GDI+ functions. Once these drawing operations have completed, the buffer contents are drawn, or ‘flipped’, very quickly to the output screen.
To use double buffering, an in-memory bitmap needs to be created specifying the size of the screen or window to which the graphics will ultimately be rendered. An example can be seen below.
Bitmap* pMemoryBMap = new Bitmap(lWidth, lHeight);
The next step requires the creation of a graphics canvas associated with the new bitmap above. This canvas will be used draw our individual graphics objects to the buffer.
Graphics* pCanvas = Graphics::FromImage(pMemoryBMap);
Remember to paint the buffer background a particular colour at this point – white in the example below.
Color backgroundColour(0xFF, 0xFF, 0xFF, 0xFF);
pCanvas->Clear(backgroundColour);
All graphics objects can now be drawn to the buffer as if they were being drawn on screen directly. When all drawing has been completed, a new graphics canvas should be created, but this time it should be associated with the actual output screen or window, as detailed below.
Graphics* pGraphics = new Graphics(hWnd);
Now, the buffered graphics can be rendered to the screen using the DrawImage method of the graphics canvas, as detailed below.
pGraphics->DrawImage(pMemoryBMap, 0, 0);
The contents of the buffer should be displayed instantly without any lag. Aesthetically, it is more pleasing to see a scene rendered completely than to be able to see the individual graphics objects being drawn one at a time.
Now, how does use of a cached bitmap help the performance of an application? Well, the main reason for using a cached bitmap is to aid in the re-drawing of the current screen or window when a WM_PAINT message is received. Typically, an application will have moved on by drawing it’s next off-screen buffer and will use a cached bitmap to refresh the current screen contents, if required, before the next buffer is flipped to the screen.
A cached bitmap should be generated, as detailed below, from the off-screen buffer after the contents of the buffer have been flipped to the screen.
CachedBitmap* m_pCachedBitmap = new CachedBitmap(pMemoryBMap, pGraphics);
Note, in addition to a pointer for the off-screen buffer, a canvas pointer associated with the actual output screen must be supplied when the cached bitmap is created. Should the current screen output need to be re-drawn, perhaps in response to a WM_PAINT message as described above, the cached bitmap can be displayed as follows.
pGraphics->DrawCachedBitmap(m_pCachedBitmap, 0, 0);
Use of a cached bitmap, as described above, should ensure that your screen or window is re-painted smoothly without any flickering. When the contents of your display need to be completely refreshed, double buffering will allow the screen to be rendered in its entirety, in one pass.
Registry Free COM
Windows Vista has been available now for a few months and developers are starting to discover the pitfalls of deploying their (older) applications on this platform. Many are finding that dlls used by their applications are failing to install correctly. This failure is due in part to Vista’s much publicized User Account Control (UAC).
The affected applications are typically using ATL dlls, which need to be registered on the host OS, prior to the applications being run. Due to Vista’s UAC, regsvr32.exe fails displaying an error message and hence the registry keys associated with these application dlls, are not copied to the system registry. When run, applications so affected would either terminate prematurely or fail when features are found not to be available.
To ‘fix’ the above situation, regsvr32.exe could be elevated to run as an Administrator – this would have to be done for each ATL dll used by a particular application. Alternatively, the application and associated dlls could be converted to employ registry free COM. This feature copies all dll registration information into an XML manifest. Each of these manifest files can then be incorporated into the associated application manifest which, in turn, is compiled into the application executable.
Deployment of an application, which has been altered to support reg-free COM, is much simplified; the executable and associated dlls can be copied directly from the installation media to the target application directory on the host PC. An added bonus is that there should be no need to re-start the system after the installation has completed.
So, having described reg-free COM above, how is an application altered to support it? Well, the good news is that the only changes required are to the application and dll properties, from within Visual Studio. For an ATL dll, you should open the project’s property page and expand the Manifest Tool group (figure 1). Then, enter the name of your dll’s type library into the Isolated COM section. You should also enter the name of your dll in the Component File Name field.
Figure 1, manifest tool properties
Before building the dll, check that the Generate Manifest and Allow Isolation fields are set to yes in the Linker group/Manifest File section – these are usually set to yes by default. Having performed this check, the dll can now be built as normal and a manifest file will be generated containing XML formatted registration information.
The final step involves incorporating the information contained in each dll manifest into the application manifest. This, at first glance, seems quite daunting but the process turns out to be straight forward. All you need to do is to specify the name and location of each dll manifest in your application’s properties (figure 2). To do this, open the application property page and expand the Manifest Tool group. Enter the dll names and paths into the Additional Manifest Files field then check that the Embed Manifest field is set to yes. You are now in a position to build the application.
Figure 2, additional manifest files
You should test the application on a ‘clean’ system, one on which the application dlls have never been registered. Probably the best way to perform testing of this nature is on a virtual machine running under Virtual PC. Note, if the application or any of the associated dlls have dependencies which have not been copied/installed to the test system, an error box will be displayed complaining about an ‘incorrect configuration …’.
Registry free COM is supported, at the time of writing, on Windows XP SP2, Windows Server 2003 and Windows Vista. The registry free COM configuration steps detailed above refer specifically to Visual Studio 2005.
Using Microsoft’s XML Parser
Most software developers, irrespective of the language they are using, will be faced with the task of re-writing code for reading/writing application data and configuration files. Each new application seems to have slightly different requirements for these files and much time is spent altering and adapting old code.
In an attempt to avoid the above situation, I started using XML for both of these file types. Microsoft’s XML Parser, via a parser ‘facade’ class, was used for the basic read and write operations along with some error checking. All I would need to do for any new application, would be to convert the application data to XML and call the appropriate facade method.
Once I started using the parser, I quickly discovered that you could run complex queries against the recorded XML data, using the parser’s XPath language. This added a whole new level of flexibility to the retrieval and display of application data. As a bonus, with the release of Microsoft Office 2007 and its Open XML file formats, applications can now conceivably generate files which can be used directly by Word, Excel or Powerpoint.
If you have not used Microsoft’s parser in a C++ environment before, the rest of this article should help ‘kick start’ your development activities with this tool. I have assumed the reader has a basic knowledge of COM/ATL development – a detailed discussion of the associated data types however, lies outwith the scope of this article.
So, as a first step, you should download a copy of the parser SDK from the MSDN download page. The current version, at the time of writing, is six. It includes the parser dlls and the appropriate header and lib files. Once you have installed the complete SDK, set up your Visual Studio include and lib file paths to point to the corresponding SDK directories.
In your application include the header file msxml6.h and, in project properties, insert msxml6.lib in the linker ‘Additional Dependencies’ section. You are now ready to create an instance of the parser via a call to CoCreateInstance, as detailed below.
::CoCreateInstance(CLSID_DOMDocument60, NULL, CLSCTX_INPROC_SERVER, IID_IXMLDOMDocument, (void**)&m_pXMLDoc);
In the above function call, CLSID_DOMDocument60 uniquely identifies the version number of the XML parser – there may be several versions of the parser installed on the host PC. IID_IXMLDOMDocument indicates the desired interface, to be returned via m_pXMLDoc, when the parser is created. In this case, CoCreateInstance function should return a value of S_OK.
Assuming that CoCreateInstance has completed successfully and a valid document interface pointer has been obtained, you should now set any required parser properties before loading an XML file. As a minimum, you should set the parser async and SelectionLanguage properties as detailed below.
VARIANT_BOOL vAsync = VARIANT_FALSE;
m_pXMLDoc->put_async(vAsync);
CComVariant vSyntax("XPath");
BSTR bstrLanguage = ::SysAllocString(L"SelectionLanguage");
m_pXMLDoc->setProperty(bstrLanguage, vSyntax);
Consult the MSXML 6.0 Parser SDK help files for a complete list of parameters and their associated values.
Now, to load an XML file, simply call the document ‘load’ method. Note, the contents of the current parser document will automatically be discarded when new XML data is read from file. Use the document ’save’ method if you need to retain any changes to the existing document, prior to loading new XML data. Loading an XML document into the parser is detailed below.
VARIANT_BOOL vStatus = VARIANT_FALSE;
CComVariant vXMLFile(bstrFilename);
m_pXMLDoc->load(vXMLFile, &vStatus);
where bstrFilename is the full path of the target XML file. You should check that the load function returns S_OK and that the vStatus parameter has a value of VARIANT_TRUE. You can now query the document, or call other document interface methods to alter the data, as required.
A ‘bare bones’ parser facade class, based on the details presented above, can be downloaded from the ayrware downloads page.
