Clone this wiki locally
For all of our projects, it's incredibly important that things are kept as simple and user-friendly as possible. Our work is not for developers, it's for people who are less familiar with code, and/or just want to get things done. We're far less interested in features to make the environments more powerful for advanced users than we are in features that make it easier to handle tasks that are common for a wide range of our audience.
In addition to this list, we are track specific bugs and enhancements via github issues:
- Processing documentation
- p5.js documentation
- processing.py documentation
The Processing Foundation has participated in Google Summer of Code since 2011. This year we are again applying to be a mentoring organization for Google Summer of Code for 2016. If we are accepted into the program, we will update this page will links and information on how to apply.
Unfortunately, the Processing Foundation did not become accepted for this year’s Google Summer of Code (GSoC) as a mentor organization. Here is a complete list of the accepted orgs.
Previous year GSOC reports
To get a sense of the kinds of project we work on via GSOC, take a look at these reports.
Strategy / Outreach
- Community outreach initiatives, especially those aimed at reaching and supporting more diverse audiences.
- Studying and improving p5.js community management, with a focus on project and community growth and sustainability.
- Studying and improving p5.js development workflow processes (sometimes referred to as DevOps).
- Improving documentation for contributors, to make it more accessible for beginners.
- Creating an addon library for other functionality that could be integrated with p5.js. (Ex: OSC, local storage, database)
- We are currently in the process of building a p5.js web editor. See the issues list for ideas.
Improving and Developing Functionality
- Fixing bugs!
- Working on features for Processing and p5.js to support accessibility, making it easier to use for seeing or hearing impaired programmers.
- Continued development of [WebGL/3D functionality]. See more info.
- Adding and improving p5.js website, reference, example generation scripts.
- Python Mode for Processing allows you to write Processing sketches using the Python programming language. We are looking for help with the implementation of Python Mode and its documentation.
- Python mode is not currently compatible with the 3.0x releases due to recent changes in
PApplet. This is one major task we are looking for help with.
- Is there something you think Processing should do, but it currently doesn't? Processing can be extended through libraries and we're always looking for contributions. Instructions for building libraries are here on the GitHub wiki.
- The libraries that allow Processing to communicate with the MS Kinect are out of date and in need of updating. This includes openkinect and simpleopenni.
- Some useful 1.x libraries still have not been updated for Processing 2/3:
- Invent your own idea for a library!
Tools for the Processing Development Environment (PDE)
- We've build a system that allows the PDE to be extended to enhance the action of programming. There's an extensive list of potential tools on the Processing Wiki that are waiting to be programmed. Instructions for building tools are here on the GitHub wiki.
- The video library for Processing uses an engine built on top of GStreamer. During GSOC 2014, Roland Elek created a system to generate the Java bindings for GStreamer 1.x automatically from the .gir files. Although the major hurdle has been solved, some issues still need to be addressed (memory management, higher level API) in order to make the new bindings usable from Processing.
- As a entirely different direction of work, we could look into alternative low-level libraries for video playback and capture, ideally lighter than GStreamer. Some options that appear to be actively developed right now: Webcam capture, jlibav, the FFmpeg components in JavaCV and its capture modules (libdc1394, FLYCapture, etc.)
- The two previous items are quite ambitious in their scope (updating to gstreamer 1.0, replacing the underlying video toolkit altogether), but there are plenty of smaller tasks/project ideas that are still very important:
- We'd also like to support for as many capture devices as possible, this requires substantial amount of testing and could lead to write/improve gstreamer plugins for video capture. The wiki entry for the Video Library has some relevant information for capture plugins on OSX, specifically related to the issue of listing available capture devices which might be problematic given some changes in the gstreamer API in the 1.0 release.
- The property-probe interface in gstreamer 0.10 that allowed to retrieve the list of available capture devices has been removed in 1.0, but there is now a replacement that is already included in GStreamer 1.2. Making use of this new device discovery/listing API would require changes in the video library as well as in gstreamer-java.
- Investigate ways of improving playback to allow for smoother scrubbing of a video. The Processing Forum contains some discussion about this issue.
- From an old GSoC 2012 thread, we could consider the following (relatively) simpler tasks: better error handling (showing descriptive warnings when there are no cameras available, or the selected framerate is not supported), clean-up the GStreamer plugins that are bundled with the video library from those that only support esoteric codecs and functionality that are not needed in Processing, and thus making the library smaller.
- The Shader API in Processing 3.0 will be complete (after implementing #2963), so this could be a good time to start compiling shader examples and effects in a centralized location. Also, an advanced shader tutorial following the introductory one here is also needed.
- Right now, editing of GLSL shaders is not supported by the PDE. An external tool allowing to code shaders side by side with the sketch code could be very useful.
- Working in collaboration with the p5.js team to implement the shader API in a webGL renderer for p5, that ideally can share GLSL shaders seamlessly between Processing 3 and p5.js
- Visual quality fine-tuning: although the OpenGL renderer primary aim is performance rather than quality, work has been done in Processing 3.0 to make the output of P2D and P3D as good as possible - within the constrains of OpenGL - and specially when comparing P2D with the default renderer (JAVA2D). There are still several bugs related to visual quality that could be taken care of, for example: #115, #1185, #1997, #2014, #2018, #2065.
- A library to do calculations on the GPU using the OpenCL API. This library could work in coordination with the OpenGL renderers to allow handling large particles systems, very complex dynamic meshes, etc. A prototype OpenCL library for an early Processing 2.0 alpha release, which implemented traer.physics solvers with OpenCL kernels, is available here.
Processing for Android
- Additional Libraries to extend support to mobile device APIs for networking, mapping, and reading sensor data. We'd like to start with simple examples for different features (as we've done in the most recent release), and as these are ironed out, make them into libraries. We are not looking for a monolithic library to support all types of sensors, but lots of small examples of how to use different features. These libraries are not intended to be comprehensive, but rather focus on simple ways of using devices.
- Video/Media library for Processing Android? This would probably wrap the media engine and player already available in Android.
- Interface/back-end: In release 0194, the run/stop/cancel interface took a step backwards, as changes were made to get things working under the new 'mode' system. This needs some care. It involves staring at some difficult multi-threaded code that handles the build and run cycle, launching an emulator, making sure that an AVD is setup and installed, and so on. In addition, on Windows in particular, we aren't getting very helpful errors out of the ant build scripts. Some tinkering should improve the situation. All this is very important for Android development.
- Bug Exterminator: The software always has issues to be dealt with. In addition, there are web site and reference issues. Contributions are always welcome!
- Bug Evaluator: Our forum tends to fill up with reports of actual bugs, while the issues list fills with nitpicks that aren't really bugs. Someone to deal with these things and assess the real situation would be huge.
Smaller, Isolated Projects and Fixes
There are a number of smaller projects that could be handled by someone who doesn't necessarily want to dive all the way in to the code. These are isolated things that I've just never had the time to get around to. We track many of these with the help label. Here are a couple to point out here:
- Undo is not behaving properly (issue 707). Also related is how sketches are being set modified: sometimes too aggressively, because some key events are coming through as text being typed when they're just modifiers like the alt key. Oh the embarrassment.
- We've encountered some difficulty supporting all the OS features for Apple retina displays. We could use some help in tracking problems related retina displays and providing fixes. For example, see
issue 2116 andissue 2117.