Java: Graphics in Linux

Question

Does X-Windows have to be installed on a Linux-box in order for Java to display fullscreen graphics?

Answer 1

Well "fullscreen graphics" is a bit vague.

Anyway, apparently there is a an effort ongoing to access the framebuffer from Java: Framebuffer Toolkit.

The objective of this project is to produce a body of code which is a lightweight framebuffer-based peer implementation for AWT and Swing. The goal of this code is to remove the dependency on X or other graphics layers such that graphics can be redirected to a framebuffer (e.g. a raw buffer, VNC, etc.). This example implementation will prefer pure-Java solutions, with public extension points available to enter native resources as necessary.

See Project proposal: fbtoolkit.

Answer 2

On an embedded device, such as a Raspberry Pi, if you don't want to go through full X11 with standard Java AWT + Swing, then this https://github.com/ttww/JavaFrameBuffer project to write straight into the frame buffer seems interesting.

An alternative may be to use e.g. SWT on GTK, or Qt Jambi, to write into the Frame Buffer (both GTK and QT can directly use a FB without X11).

Answer 3

To really display something graphical on the screen, yes. Bud there is a headless version of the JRE for just running it. You won't see any graphical output, but it will run. Alternatively, you can log in remotely and use X forwarding to run the java code on the server but let the client handle displaying graphics.

Answer 4

Other answerers appear to assume that "full screen graphics in Java" necessarily means "a working implementation of AWT". This is, of course, not necessarily true, as it is perfectly possible (some would even say desirable) to use Java without AWT.

Cairo is a 2D graphics rendering library that can be used from Java, and can also be used without X11. It looks at first glance as though it should be possible to configure it for this scenario. You'll need to configure it to use OpenGL rendering, and provide a suitable non-X11 OpenGL implementation (e.g. MesaGL with the 'fbdev' device driver).

SDLJava is a Java port of the popular C SDL game development library. This also should be able to do what you ask for, although it doesn't seem to have been updated since 2005 so if you have any problems with it support may not be forthcoming.

As an alternative, you could always use some fairly simple C code to open and configure the framebuffer, and then use JNI to return the memory-mapped framebuffer as a direct-mode ByteBuffer, so you can draw to it directly.