processing-rs

An implementation of Processing for the Rust programming language, with insipriation from openFrameworks and libCinder. It has been developed by Robert Ennis in the lab of Katja Doerschner, a part of the Allgemeine Psychologie Department at the Justus-Liebig Universitaet of Giessen.

Better testing for errors is due in the coming days.

Please see the basic example for typical usage and the documentation for some explanation of the commands. Since this is modeled after Processing, you can also use their documentation for extra clarification, as well as examples of the commands.

lib.rs:

processing-rs

processing-rs is a crate that is designed to make graphics programming as easy in Rust as it is in the popular Processing environment, without sacrificing performance or easy access to other parts of your system. It achieves this by essentially being a convienence layer built on top of glium and glutin/glfw (either can be chosen depending on your preference). It mostly mimics Processing, but diverges in a few areas to either accomodate Rust's and glium's safety features or to incorporate some ideas from libCinder and openFrameworks. For instance, there are now setup and draw loops in processing-rs. This is intended to enable a more flexible and modular workflow for graphics. In addition, since processing-rs is essentialy a thin wrapper, you can use glium, glutin, and raw OpenGL calls as you see fit. They should usually blend nicely with the processing-rs calls and allow for more opportunities to create fun and interesting displays.

Typical usage follows a common pattern:

 1. Open a screen with processing::Screen::new(). This will return a 
    Screen struct, which is the central struct for coordinating draw calls,
    managing shaders, and maintaining render state.

 2. Pre-define a few shapes. This allows caching shape data on the CPU and GPU,
    giving some marginal speed boosts and allowing the possibility to store
    shapes in collections, such as Vectors. All shapes (Rect, Ellipse, etc.) in
    this crate implement the Shape trait, which defines a common interface for
    entities that can be drawn to a screen in a meaningful way.

 3. Draw the shapes to the screen with screen.draw(). This is also where you will
    want to use commands like screen.fill() and screen.stroke() to change the
    colors of objects.

 4. For any pattern drawn, you will also need to flip the framebuffers, so that
    the pattern is synchronized with your monitor. This is achieved by
    screen.reveal().

 5. Use commands like screen.key_press() to get input from users, if needed.

 6. Have fun! :-)

Basically, all commands follow the same call conventions as those from Processing, so you can also use the Processing reference as additional documentation and for some basic examples of what you can do.

Additionally, processing-rs has a number of features that are intended to make it useful for psychological research, including color vision, material perception, motion, etc. For example, it tries to enable a 10-bit framebuffer if possible, for increased color fidelity, which is important in most color vision research. Besides this, it also aims to make sure that frame draws are as precisely synchronized with the monitor refresh as possible. This works better with glutin than with glfw, and on Mac, a few Objective-C functions are called to give the program elevated status for resources and to disable AppNap and such things while the program is running (code taken from the helpful PsychToolbox). In addition, when the crate is built on a Mac, it will also compile a C library (called libpri, short for "priority library") that asks the operating system for some additional priorities. The crate will automatically call the library throguh the C FFI at screen initialization. It shouldn't interfere with normal operation of the operating system, so you can probably just accept the default behaviour. With all of this, combined with a change to a setting on Mac that allows one to quit Finder, one can achieve slightly better synchronization than PsychToolbox on Mac, satisfying Psychtoolbox's requirements for good frame synchronization. However, this has only been tested on a Mac laptop with 10.13.3 and an Intel graphics card.