Skip to content
This repository was archived by the owner on Jun 24, 2024. It is now read-only.

Home

Jump to bottom
codeanticode edited this page Apr 7, 2019 · 7 revisions

This LWJGL-based OPENGL renderer is an alternative to the default OpenGL renderer in Processing, based on the LWJGL 3 bindings. The default OpenGL renderer is uses the JOGL bindings.

Getting started

In order to get started with this LWJGL renderer, you need to clone the processing repo in addition to this repo, for example:

mkdir devel
cd devel
git clone [email protected]:processing/processing.git
git clone [email protected]:codeanticode/processing-lwjgl.git

You can follow the build instructions listed in the Processing wiki to build Processing. Once you have done that, you can add both github repos into Eclipse, and choose the projects to import. The Processing repo contains many projects but you only need processing-core in order to test the LWJGL renderer from Eclipse. The processing-lwjgl contains two projects, the rendering library itself, and LWJGL-Test with two test samples. Once all of these project are imported into Eclipse (with Processing properly built) you should get something like this:

image

The libraries in the Build Path of processing-lwjgl project assume you are on Mac:

image

so you would need to change them to the corresponding Windows/Linux jars when on those platforms.

Test code

The LWJGL-test project contains two simple test samples, one that is a basic "Hello LWJGL" application that just shows an OpenGL window and prints the mouse events in the console (it does not depend on Processing at all), and a PSketch application that uses Processing to render a 3D cube. When running these examples on Mac, you need to add the -XstartOnFirstThread argument to VM arguments under Run Configurations for each application:

image

Challenges

GLFW-AWT incompatibility on Mac

The new renderer appears to work well on Windows, however, there are some challenges to overcome on Mac. First of all, LWJGL3 uses the cross-platform toolkit GLFW to manage windows and events. GLFW requires the VM command -XstartOnFirstThread on Mac in order to function, but that command breaks AWT, as discussed in several places, like here and here.

You can see the effects of combining -XstartOnFirstThread with AWT (even just initializing AWT and doing nothing else with it) by uncommenting some of the commented lines in the initialization the HelloLWGL example.

Making AWT optional in PApplet

A solution to the above problem could be modularizing away these specific AWT-related calls in the base PApplet class in Processing, and performing them only when using the default renderers as a possible way of making Processing compatible with LWJGL and GLFW on Mac. But this would require making changes to how sketch initialization works in the core of Processing. That being said, there are only few places where Processing uses AWT, such as file selection with selectInput() that would need to move to Surface, and probably adding a few more methods to handle the init stuff that’s in PApplet.main().

A complete list of the Swing/AWT API's used in PAPplet, their role, and associated imports is below:

  • Frame dummy object for backwards compatibility. Replacing/removing this object would break older sketches that use it, but that's probably unavoidable.

    • import java.awt.Frame;

  • AWT's DisplayMode, GraphicsDevice, and GraphicsEnvironment, to get displayWidth/Height before calling settings, and to determine displayDensity and list of available graphic devices. This comment in an issue discussing the AWT-LWJGL3 incompatibility suggests that the libgdx library has new APIs to replace those functions. We don't need to incorporate libgdx into Processing, but perhaps looking into the implementation of those APIs could help in finding replacements for this AWT's graphics querying funcitons.

    • import java.awt.DisplayMode;
    • import java.awt.GraphicsDevice;
    • import java.awt.GraphicsEnvironment;

  • Swing's JOptionPane used to present the fullScreen() warning about Spaces on Mac.

    • import javax.swing.JOptionPane;

  • AWT's Toolkit and HeadlessException used inside runSketch() to warn users about headless.

    • import java.awt.HeadlessException;
    • import java.awt.Toolkit;

  • Image loading implementation, relying on AWT's Image, ColorSpace, BufferedImage, ImageIO.

    • import java.awt.Image;
    • import java.awt.color.ColorSpace;
    • import java.awt.image.BufferedImage;
    • import javax.imageio.ImageIO;

  • Use of Swing's ImageIcon when loading an image that allows to remove Processing's MediaTracker code.

    • import javax.swing.ImageIcon;

  • File and folder selection in selectInput(), selectOutput(), and selectFolder(), which rely on AWT's EventQueue, FileDialog, and JFileChooser.

    • import java.awt.EventQueue;
    • import java.awt.FileDialog;
    • import javax.swing.JFileChooser;

  • Swing's UIManager to set the look and feel.

    • import javax.swing.UIManager;

  • The implementation of link() that opens a web link using AWT's Desktop.

    • import java.awt.Desktop;

  • Swing's FileSystemView used by the desktopFile() method.

    • import javax.swing.filechooser.FileSystemView;

Using startOnFirstThread

This will require to know that the user has specified the GL renderer before starting the sketch, in order to set the startOnFirstThread VM argument (which cannot be set when the sketch the default, AWT, JAVA2D renderer). Which means either parsing the code properly or adding some setting in the PDE. The latter option is not really feasible, since a basic feature of Processing is to let users to switch renderers as they please.

Clone this wiki locally