In Xojo 2016 Release 4 we switched our main graphics rendering engine on Windows from GDI and GDI+ to Direct2D/DirectWrite. Direct2D/DirectWrite was first introduced by Microsoft in Windows 7, with support in Vista via a Platform Update. It is (or was at the time) Microsoft’s new high-performance 2D vector Graphics API.
The transition GDI to GDI+ to Direct2D
GDI is another Graphics API that was present in the initial release of Windows and to this day remains an integral part of the OS. However, since GDI is such old technology it lacks basic anti-aliasing support, alpha channel support, and still deals in integer coordinates. GDI+ was introduced in Windows XP and included everything missing from GDI, with one glaring issue, text rendering. While the appearance itself is slightly different (one of the original reasons why even with App.UseGDIPlus enabled Xojo still rendered DrawStrings using GDI text rendering), but also because of the additional text processing and resolution independence capabilities in GDI+, text rendering is performed by the CPU.
Direct2D/DirectWrite solves all those issues, and best of all it can still interoperate with GDI code which is important for Xojo Plugin developers and other parts of Xojo that still rely on a GDI graphics context (i.e. StyledTextPrinter and theme drawing). Without Direct2D/DirectWrite Xojo could not completely support HiDPI effectively. The main issue was text rendering in the code editor and swithing to GDI+ text rendering was deemed too slow. Other benefits of Direct2D/DirectWrite include: hardware acceleration, low CPU usage, improved text rendering and scaling.
Consequences of the transition
While new technology solves many immediate and future problems, it can also introduce some growing pains. For example, Microsoft didn’t introduce a printing API for Direct2D until Windows 8 (which was thankfully backported to Windows 7 via a Platform Update). This printing API has limited Xojo’s resolution setting among other things. Also, even though Direct2D can interoperate with GDI, this is not without some effort as Plugin developers have come to realize, especially when it comes to printing. For example, StyledTextPrinter is currently using an OS API that still takes a GDI graphics context (good luck getting Microsoft to update this control’s API) which now renders output as a scaled picture with how interoperating works. Other differences in rendering may be noticeable but these are likely just a difference in the graphics rendering APIs. While some consequences may be solved as time/features permit, some may be here to stay. We’ve fully embraced Direct2D/DirectWrite as our new graphics rendering engine and hope you will too.
While our framework attempts to guard one from having to learn about the underlying technology, it is still beneficial to understand why, at times, we need to make these changes. With that in mind, here’s some additional resources for those curious to learn more: