Each device-specific display library will have its own constructors and initialization functions. These are documented in the individual tutorials for each display type, or oftentimes are evident in the specific library header file. The remainder of this tutorial covers the common graphics functions that work the same regardless of the display type.

The function descriptions below are merely prototypes — there’s an assumption that a display object is declared and initialized as needed by the device-specific library. Look at the example code with each library to see it in actual use. For example, where we show print(1234.56), your actual code would place the object name before this, e.g. it might read screen.print(1234.56) (if you have declared your display object with the name screen).

Drawing pixels (points)

First up is the most basic pixel pusher. You can call this with X, Y coordinates and a color and it will make a single dot:

Characters and text

There are two basic string drawing procedures for adding text. The first is just for a single character. You can place this character at any location and with any color. An optional size parameter can be passed which scales the font by this factor (e.g. size=2 will render the default font at 10x16 pixels per character). It’s a little blocky that way but having just a single font helps keep the program size down.

Text is very flexible but operates a bit differently. Instead of one procedure, the text size, color and position are set up in separate functions and then the print() function is used — this makes it easy and provides all of the same string and number formatting capabilities of Arduino’s familiar Serial.print() and println() functions! But you precede these with the display object instead of Serial.

Begin with setCursor(x, y), which will place the top left corner of the text wherever you please. Initially this is set to (0,0) (the top-left corner of the screen). Then set the text color with setTextColor(color) — by default this is white. Text is normally drawn “clear” — the open parts of each character show the original background contents, but if you want the text to block out what’s underneath, a background color can be specified as an optional second parameter to setTextColor(). Finally, setTextSize(size) will multiply the scale of the text by a given integer factor. Below you can see scales of 1 (the default), 2 and 3. It appears blocky at larger sizes because we only ship the library with a single simple font, to save space.

After setting everything up, you can use print() or println() — just like you do with Serial printing! For example, to print a string, use print("Hello world") - that’s the first line of the image above. You can also use print() for numbers and variables — the second line above is the output of print(1234.56) and the third line is print(0xDEADBEEF, HEX).

By default, long lines of text are set to automatically “wrap” back to the leftmost column. To override this behavior (so text will run off the right side of the display — useful for scrolling marquee effects), use setTextWrap(false). The normal wrapping behavior is restored with setTextWrap(true).

Extended Characters, CP437 and a Lurking Bug

The standard built-in font includes a number of symbols and accented characters outside the normal letters and numbers you’d use in print() strings. These can be accessed with drawChar(), passing an 8-bit value (0–255, though commonly expressed in hexadecimal, 0x00–0xFF) for the third argument.

The built-in font is based on the original IBM PC character set, known as Code Page 437 (CP437 for short). Many embedded systems still use this as it’s compact and well established.

Years ago, when originally transcribing CP437 into the GFX library, one symbol was accidentally omitted. Nothing fatal, code runs fine, but every subsequent symbol was then off by one compared to the “real” CP437 character set. By the time this was discovered, so much code had been written — projects shared online but also in fixed media like books and magazines — that fixing the bug would break every existing project that relied on those extended characters!

So the error has been left in place, on purpose, but this creates a different issue if one is adapting code from elsewhere that relies on the correct CP437 symbol values.

A compromise solution is a function that enables or disables the “real” CP437 sequence. By default this is off, the off-by-one order is used, so that all the old GFX projects in books work without modification. The correct order can be enabled with:

Unless you need to switch back and forth, this typically only needs to be done one time, in the setup() function.

Here’s a map of the built-in character set, both the standard erroneous version, and the corrected version used when one calls cp437(true). Notice this only affects the last five rows of symbols; everything prior to character 0xB0 is unaffected:

The presence of the extended Code Page 437 symbols is only guaranteed in the built-in font. Custom fonts (explained elsewhere) rarely include these.

Extended characters typically can’t be directly printed in code; most editors may support Unicode strings but this does not directly map to CP437. Typically one calls the write() function with individual character numbers. The GFX library harkens back to an earlier time when Unicode support was not widespread.

Consider the German word Schön (beautiful). One might print this like so:

Likewise with accessing the math symbols…

Compiler support for some (not all) 32-bit microcontrollers provides the printf() function, which can allow these characters to be placed inline via the %c (character) formatting identifier:

This is nice and compact but isn’t compatible with all microcontrollers, certainly not early Arduino Uno-class devices, so consider how you might be sharing code and use it with care.

See the “Using Fonts” page for additional text features in the latest GFX library.

Bitmaps

You can draw small monochrome (single color) bitmaps, good for sprites and other mini-animations or icons:

This issues a contiguous block of bits to the display, where each '1' bit sets the corresponding pixel to 'color,' while each '0' bit is skipped. x, y is the top-left corner where the bitmap is drawn, w, h are the width and height in pixels.

The bitmap data must be located in program memory using the PROGMEM directive. This is a somewhat advanced function and beginners are best advised to come back to this later. For an introduction, see the Arduino tutorial on PROGMEM usage.

Here's a handy webtool for generating bitmap -> memorymaps

Clearing or filling the screen

The fillScreen() function will set the entire display to a given color, erasing any existing content:

Hardware-Specific functions

Some displays may have unique features like screen invert or hardware-based scrolling. Documentation for those functions can be found in the corresponding display-specific guide. Since these are not common features across all GFX-compatible displays, they are not described here.