Home > Java > Java fullscreen graphics – reporting basic graphics capabilities

Java fullscreen graphics – reporting basic graphics capabilities

I’ve been toying with the Java full screen graphics capability recently, just to get a handle on how it hangs together since I’m becoming somewhat tired with writing windowed apps. It’s admittedly complex but like most complex things can be broken down and composed into separated tasks and components.

As part of the experimentation process I did what I usually do when presented with a complex problem, which is to find a logical start point and work my way around from there, the logical start point in this case being the java.awt.GraphicsEnvironment which typically describes the graphical environment of the machine you are working on (although it can be used to describe a remote machine). Extending out from there it is a fairly seamless process to define the graphics environment you are confronted with e.g.

import java.awt.DisplayMode;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Rectangle;

public class GraphicsReportManager {
    protected GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
    protected GraphicsDevice gd = env.getDefaultScreenDevice();
    protected boolean fullScreen = gd.isFullScreenSupported();
    protected Rectangle r = env.getMaximumWindowBounds();
    protected double ht = r.getHeight();
    protected double wt = r.getWidth();
    protected GraphicsDevice[] gdArr = env.getScreenDevices();
    protected long fastMem = gd.getAvailableAcceleratedMemory();
    protected GraphicsConfiguration[] gc = gd.getConfigurations();
    protected DisplayMode[] dm = gd.getDisplayModes();

    public void printGraphicsReport()
        System.out.println("Current Full Screen support: " + fullScreen);
        System.out.println("Dimensions: " +  ht +  " * " + wt );
        if(fastMem < 0)  // not all systems will report fast mem and will return a negative int showing state unknown
            {System.out.println("Available accelerated memory undefined");}
            { System.out.println("Available accelerated memory: " + fastMem); }

        int len = dm.length;
        System.out.println("DisplayModes = " + len + " & are: ");
        StringBuffer sb = new StringBuffer();
        for (int i = 0; i < len; i++) {
            sb.append(dm[i].getHeight()).append(" * ").append(dm[i].getWidth());
            sb.append(" ");
            sb.append(" Depth: ");


This will give us the basics of what we need to know, but obviously there is room for further definition of graphics capabilities and I will be building these up along the way as the need arises.

Getting font details back initally from GraphicsEnvironment looks to be a time-expensive operation (it feels slow and if it feels slow it probably is). However the reality is you may need this information so you could supplement the class with the following methods:

public void printAllAvailableFonts()
    String[] sFonts = env.getAvailableFontFamilyNames();
    int len = sFonts.length;
        for (int i = 0; i < len; i++) {
            String string = sFonts[i];
public void printAllAvailableFonts(Locale locale)
    String[] sFonts = env.getAvailableFontFamilyNames(locale);
    int len = sFonts.length;
        for (int i = 0; i < len; i++) {
            String string = sFonts[i];

The overloaded method is potentially handy if you need to see only fonts for a particular language locale or the current locale. Constructing a Locale object is easy enough. You can either do this to get the current Locale

 Locale loc = new Locale(System.getProperty("user.language"),System.getProperty("user.country") );

or you can just pass it the String name of the language you’re interested in e.g.:

Locale loc2 = new Locale("en","US");

(See also this page for more on constructing Locales)

Footnote (later)

I think I am probably going to abandon this experiment in Java, much as I would like to do it this way, and write the mini-app I had in mind properly in C++. The graphics stuff in Java still really isn’t good enough & is the wrong side of unpalatably messy; double-buffering as a strategy to reduce screen flicker is a real killer (for a revealing take on this see this c2 wiki link).

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: