JobQueue / Calling OpenGL methods from different threads

A lot of people probably already have implemented some sort of system like this, but it might be interesting enough for some others.



It's provides the ability for different threads to add jobs (a implementation of Runnable) which will then be run from a different context, for example from the jME one.

This should make it easier to do things like background loading of textures, since the OpenGL part of it can then be stuffed into a Runnable and then added as a synchronous or asynchronous job. The difference between asynchronous and synchronous jobs is that the latter one will block till the job has been executed. The oldest job in the queue will be run by calling runJob() (you can also run the oldest n by calling runJob(n)), preferably in update(int) or simpleUpdate().



Oh yeah, the design and idea of this is a shameless rip of what is done in SWT.



JobQueue.java


/*
 * Copyright (c) 2003-2006 jMonkeyEngine
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are
 * met:
 *
 * * Redistributions of source code must retain the above copyright
 *   notice, this list of conditions and the following disclaimer.
 *
 * * Redistributions in binary form must reproduce the above copyright
 *   notice, this list of conditions and the following disclaimer in the
 *   documentation and/or other materials provided with the distribution.
 *
 * * Neither the name of 'jMonkeyEngine' nor the names of its contributors
 *   may be used to endorse or promote products derived from this software
 *   without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/**
 * <code>JobQueue</code> provides the ability for threads to run jobs in a
 * different master thread. All jobs will be executed under that thread, which
 * is the one calling {@link #runJob()} (or {@link #runJob(int)}). This class
 * can be used to call OpenGL functions from other threads which enables things
 * like background loading of textures. Jobs can be run in a asynchronous or
 * synchronous manner. Asynchronous means that the thread adding the job will
 * not wait for it to be executed. Adding synchronous jobs will block the
 * current thread till the job has been executed.
 *
 * @author Frederik B

I hear that you absolutely must run Open-GL operations from the rendering thread. So is this a way for other threads to queue Open-GL jobs for the main rendering thread to execute? If so, doesn't that limit the functionality since you're not really outsourcing the jobs to other threads?

Forgive my ignorance of the topic, I'm wondering how this would be useful in splitting loading into its own thread.

Gaheris said:

This should make it easier to do things like background loading of textures, since the OpenGL part of it can then be stuffed into a Runnable and then added as a synchronous or asynchronous job.


OpenGL doesn't support multithreading. That means that you can't "stuff" the OpenGL part in a Runnable.
Still, Texture and Image in jme aren't directly related to OpenGL, so i suppose you could do some background loading. The problem would then be that while the program runs the main loop, and might already need the textures you are loading, they might not be available yet. In such a case you would have only a few possibilities:
* somehow apply the textures only when they are available (loaded) or use a replacement "no texture" texture --> this would degrade the graphic aspect of your program and the user would actually perceive such effects as bugs. so this is no acceptable solution imho.
* you could do some intelligent preloading so you load textures you intend to use. but you have to make sure that at the moment you use them they are really available.  :|

otherwise i suggest you stick with blocking (single-threaded) loading operations.

I'm not sure you understood what that code actually does. The Runnable implementors (jobs) are executed in the context of the main jME (OpenGL) thread.

I know that OpenGL does not support multithreading, that's why I wrote this, so you can do file IO (loading your game data) in your worker thread and then do the OpenGL related stuff in a synced job. This should make it possible to have nice, animated loading screens because the main rendering loop is not blocked by some long running operations (file IO).



However, renanse did the same thing before and llama has some really fancy code, much better than the code I've posted here.