At the heart of the DisplayCore design is its modular nature. Allowing you to choose which modules you include in your software means less wasted or redundant code.
At the top of the hierarchy is the master DisplayCore class. This handles all the drawing routines and defines the standard interface for all display devices and image handling classes. From this descend the display devices themselves and the classes to display and manipulate image files. This means that all the display devices get the same standard interface with the same standard functions. A display device is now a light-weight abstracted object which just has to implement the initialization of and communication with the display itself. A display class can also override a number of the DisplayCore functions to provide hardware accelerated functionality for even faster drawing routines.
The heirarchy also means that images themselves are effectively classed as display devices, and indeed the Framebuffer group of image classes leverage this to create off-screen drawing areas for fast preparation of display data. Anything you can do on a display you can do with a Framebuffer object, and theoretically any image format could be manipulated in this way.
Image classes also reference the Filter class. This provides powerful real-time manipulation of images with respect to such things as brightness, contrast, colourising, film grain, and more. Yes, even Framebuffers, since they are just Image objects, can use filters.
Descending from the Image class is the Widget class. This effectively turns images into interactive objects with event handlers (tap, press, release, drag, etc) for creating rich interactive displays.
Touch screens also provide a standard interface through the Touch interface class.
With this design it is possible to completely change your software from using one display system to a completely different one (even a different display technology entirely) by just changing a handful of lines.