| Because of the wide variety of graphics output devices, from video displays to laser printers and plotters , the most important characteristic of any graphics API is device-independence. Without device-independence, the application programmer would be faced with great complexity and the chore of implementing many versions of the same graphics programs. Figure 11-1 illustrates the basic architecture of a graphics system. An application calls functions that are provided by a graphics API. Each supported graphics device comes with a suitable driver. The graphics system takes care of translating device-independent calls into device-specific calls through the driver. Figure 11-1. Architecture of a typical graphics system.  The original GDI does indeed provide such device-independence, but in a manner that is specific to Windows, and the API reflects this Windows orientation. The API is quite difficult to use, and there are a number of pitfalls. The interface to the GDI is defined in C, and programming to it requires the use of numerous complex structures. Some encapsulation was achieved for C++ programmers by a set of classes, which were part of the Microsoft Foundation Classes (MFC), but these classes are a rather thin wrapper around the GDI, and are only useful for C++ programmers. The .NET Framework provides a higher level of abstraction, making the API easier to use. And, like other classes in the .NET Framework, the GDI+ classes are equally accessible from any .NET language. Thus, in particular, Visual Basic programmers now have a powerful graphics API that is also easy to use and can be called natively from VB.NET applications. | 
