Project Background
July 22, 2006


SuperGraphics came about because of two problems with graphics support in REALbasic: The first is that REALbasic’s graphics support is out-dated — it’s stuck in the QuickDraw model while the rest of the world has moved on to advanced models like display PostScript, CoreGraphics, & GDI+.

Sure, “Rb supports CoreGraphics through the Graphics class on OS X” you say. Unfortunately, Rb’s implementation of CoreGraphics is nothing to write home about: drawing commands are still limited to integer coordinates and the only practical difference in quality between .UseOldRenderer being TRUE or FALSE is the anti-aliasing. In addition, line and primitive rendering exhibit pixel-level inaccuracies because the CoreGraphics drawing commands used by REALbasic still need to support older versions of OS X – back to version 10.1.

Object2D does not make things much better either because it’s routed to the screen through the built in Graphics class — This ends up leaving FigureShape objects lumpy due to polygonization and integer placement of segment endpoints, for example. Saving vector data to disk is limited to the obsolete PICT format on Macintosh or EMF on Windows, and don’t even think about printing text from Object2D.

The second problem revolves around code flexibility: Say you’ve just written some code that produces fancy graphics output on screen. How do you take that same source code and produce a higher resolution version? A PDF version? an SVG version? an EPSF version? Or how about recording the drawing commands for playback at a future time or even on a remote computer? The short answer is, it’s not easy. That leaves someone with the very common task of say, writing graphing software, duplicating a lot of effort to produce one version of a graph for screen viewing and a second for high-resolution printing.

As a computer graphics development company that relies on REALbasic every day, we find this a tough boat to be in so that’s why we’re writing SuperGraphics.


SuperGraphics is a framework for generating “multi-target” output from a single-to-use API. The framework consists of a core, abstract class, SuperGraphics, that abstracts all drawing functionality. Subclasses of SuperGraphics implement their own particular output, whether that is CoreGraphics, SVG, etc. As a developer, you draw your graphics through the SuperGraphics API while the subclasses take care of the implementation details for their own API or format. Example: When your code needs to draw a graphic to screen, simply instantiate a SuperGraphicsCoreGraphicsBitmap object and pass it to your drawing code. When you need to export a PDF, instantiate a SuperGraphicsPDF object and pass it to the exact same drawing code.


The SuperGraphics API abstracts functionality well enough to implement many different & modern drawing APIs and graphics formats. For instance, the SuperGraphics class could be subclassed to produce nearly identical output from the following graphics formats and APIs:

  • CoreGraphics Bitmap (OS X)
  • CoreGraphics PDF (OS X)
  • PDF (any platform)
  • SVG (any platform)
  • EPSF (any platform)
  • GDI+ (Windows)
  • Rb Graphics/Object 2D (any platform)
  • JavaScripting Adobe Illustrator (OS X or Windows)
  • OpenGL (any platform)

In addition, two very useful subclasses are possible that are not related to any existing graphics API or format:

  • A subclass that records, plays-back, saves to disk & loads from disk, SuperGraphics drawing commands
  • A subclass that repeats the SuperGraphics drawing commands to an array of SuperGraphics implementations, making possible, for example, simultaneously drawing to screen while saving a vector format version to disk.

Functionality is not limited to GUI applications either, it is possible, for instance to write an SVG server application: Take the SuperGraphics SVG implementation & the recorder subclass mentioned above and wrap them in a console application — your input would be a text file of drawing commands and your output would be a finshed SVG file.


The API is still in development but is about 95% complete. I’ll talk about the specifics of the SuperGraphics API in future posts, as well has how tricky things like fonts are handled in a cross-platform way.

We are developing SuperGraphics with the following complete implementations:

  • CoreGraphicsBitmap
  • CoreGraphicsPDF
  • SVG
  • Graphics command recorder
  • Graphics command repeater

Currently, the CoreGraphicsBitmap and SVG Implementations are about 95% complete. The images at the bottom of this page link to samples of each of these formats. To view the SVG file in your browser you will need the Adobe SVG Viewer plug-in.

Open Source

Finally, we hope to release SuperGraphics as open source software. Because this software is designed to be used in real-world production environments; we think it is far better if potentially anyone could tweak, fix, or update the code as necessary.

Click the image above for a GIF of the full-sized output produced by SuperGraphics' CoreGraphics Bitmap implementation. Note: CoreGraphics gradients have not been implemented yet (the upper-right 2 rows of rectangles)

Click the image above for an SVG of the full-sized output produced by SuperGraphics' SVG implementation. The output for this SVG has been set to be screen-aligned for optimal viewing in the Adobe SVG Viewer. (Don't forget to use SVG Viewer's contextual menu commands to zoom in and move around the image!)

Click the image above for a ZIP archive containing an SVG file and an externally linked PNG file. The output for this SVG file has been set to be screen-aligned for optimal viewing in Adobe Illustrator. Note: Adobe Illustrator does not import gradients with transparency (the upper-right row of rectangles).