In the first part we’ve identified several problems that we’d like to fix today:

• primitive/polygon submission is not optimal and requires way too many GL calls
• we switch GL state very often, especially enabling/disabling texturing while rendering and switching the current texture costs performance
• we enable/disable and change the clipping rectangle very often (eventually)
• we change other states like the blend mode. Not a lot but it is still happening if you ask for it within your screen (f.i. using some effect)

So let’s tackle these issues one at a time.

I won’t go into the specific OpenGL methods too much and will concentrate more on the “Nifty” side of things. You can read up the OpenGL calls elsewhere. But the interesting part – at least for me and I hope for you as well – is to connect all the dots and combine the individual pieces to optimize Nifty.

So without further ado let’s rock.

Optimize polygon submission

Well, that one is a no brainer since vertex arrays have been a part of the OpenGL spec since the very early OpenGL 1.1 days (1995 or so). The idea is to put all of your vertex data into an array and then give OpenGL a pointer to that array and tell it in a single call: now go and render all of them. Since I’d like to keep the current LWJGL renderer compatible with legacy OpenGL (for now, be patient ^^) I’ve used plain old client-side vertex arrays. This means that all of the vertex data is stored on the CPU and is only send to the GPU for rendering. This allows us to take advantage of the GL_QUADS rendering mode (which has been optimized away from core profile unfortunatly).

So for each Nifty RenderDevice render*() method (renderQuad() or renderImage()) we add four vertices to the vertex buffer representing a single quad. When Nifty later calls the endFrame() method we render all of the quads with a single glDrawElements(GL_QUADS) call. This way we can remove a couple of hundred individual glBegin()/glEnd()/glVertex() calls and GL can now take our buffer, process it in one step and render it! Much faster!

Great! We’re done! Woohoo!

But wait, what do you say? We’re not finished yet? What’s with all of the texturing and what is with font rendering? And what if we want to render a single colored untextured quad like a Nifty panel with a plain backgroundColor? Wouldn’t we have to disable texturing somehow in between all those quads in the vertex array?

Of course you’re right – readers are always right So let’s continue.

Disable texturing while rendering with a vertex array

If we would enable/disable texturing all the time or switch the current texture while we’re rendering our quads we would end up with individual render calls again. In the end all of our performance gains would have been lost again. So what should we do?

Our first trick is to let texturing enabled all the time. We’ll simply submit textured quads only – all the time. To render a plain colored quad we’ll reserve some pixels of a plain solid color in our texture, let’s say white. If we then render a quad with texture coordinates of this white piece of the texture we would end up with a solid white quad – and this quad could really be any size we want since it doesn’t really matter if we would stretch a single white pixel to the size of the screen. It would still be white

So that’s great. We can render white colored quads. Yeah! But what about other colors? Ok, that’s easy as well. We attach vertex colors to our vertices. To render a plain colored red quad for instance, we’ll set the vertex color of each vertex to red and in the end we’d have a red quad instead of a white one. And btw. this allows us to add support for linear gradients as well when we use different colors.

So to summarize our vertex data, here are the components we store per vertex in our array:

• The position of the vertex. At the moment we’re only 2d so two floats should be appropriate (x and y coordinates)
• The texture coordinate for the vertex (u and v, 2 floats as well)
• A color for the vertex. That will add 4 more floats.

So there is no need to disable texturing at all! If we want to render a plain colored quad we’ll simply adjust the texture coordinates of that quad in our vertex array to match up with the plain colored area in our texture.

Switch the current texture while rendering with a vertex array

Finally we’ll need a way to render different textures. The solution to this is simple in theory but was a bit more involved in the end.

The idea is to combine all of our individual images into one big texture. The name for this optimization technique is “texture atlas” or “texture packing”. In most cases you would combine your textures into a bigger one as a pre-process using some custom tool. But for Nifty we’ll need to do that dynamically. Let’s enter the world of texture packing algorithms also known as bin packing.

Well, as it appears this topic is a huge one! There are even PhD Thesis discussing this in depth (The PhD Thesis of Andrea Lodi f.i.: Algorithms for Two Dimensional Bin Packing and Assignment Problems).

One of the more simple algorithms and the one we’ll use for now is the Lightmap Packing Algorithm by Black Pawn and the Java port of this algorithm done by lukaszdk.

The Java version of the Texture Atlas Generator is meant to be used as an executable jar that combines multiple textures into a bigger one using java.awt.image.* stuff. Not bad but for Nifty we’d like to do that on the fly and we’d like to separate the actual algorithm from the actual handling of the graphics. In the end the algorithm can work independently of the actual graphics data. So we’ve modified his code a bit. If you’re interested in the details you can find our version in the TextureAtlasGenerator class. This class can be used on its own since it is self contained and doesn’t need any Nifty dependencies at all – if you ever need a similar algorithm

So we’ll start with a big texture (something like 2048×2048 pixels works very well so far) and as Nifty loads images we’ll put them into this texture at positions the TextureAtlasGenerator calculates for us. And with that in place switching textures actually only means changing the texture coordinates according to the data that the TextureAtlasGenerator has generated. And voila we can keep rendering all of our quads in a single call using the same big texture!

Managing image resources

The texture atlas will be filled with images for the current Nifty screen. This way all images used will be part of the texture atlas. To do that Nifty keeps track of which image belongs to which screen when it reads a XML file or when a screen is created with the Builder pattern. This tracking is done for all loaded screens and even for images that are dynamically created with Nifty.createImage().

In general Nifty will make sure that it uploads all images that are required for a screen when the screen is started (and gets active). Consequently when a screen ends the texture atlas is being reset to an empty one.

Nifty already implemented a reference counting mechanism to keep track of loaded images. This was used to prevent loading the same image multiple times and it is still being used for this purpose. However, the process of loading an image is now separated into two steps:

1. the actual image data is loaded into whatever image representation an implementation supports (for instance the implementation using native LWJGL will simply load an image file into a ByteBuffer) and

2. the loaded image data is put into the texture atlas at a position that Nifty decided when it’s time for this image to be a part of the current screens texture atlas.

When an image is accessed dynamically while a screen is running it will be uploaded at the time of the first access. For best performance static images – or at least ones that Nifty knows about before the screen is started – should be preferred so that Nifty can upload them to the texture atlas at the time the screen starts and not while the screen is already running. Although I think you can get away with a couple of image uploads if you don’t access too many new images at once.

All of this is required to keep only the currently active images in the texture atlas. This should work quite well for most use cases. However, it’s still possible to use up all of the available space in the texture atlas. In that case Nifty will complain in the log but there will be missing images. All of the Nifty examples run well with a 2K (2048×2048) texture so far. The batch renderer provides a better rendering performance but you might want to plan for some additional tests to check if all of your images fit into the texture.

Clipping

Nifty allows you to clip child elements to the area of it’s parent element. This way only the part that intersects with the parent element will be displayed. The original Nifty renderer used glScissor() for this prior to rendering the child elements. The problem with this approach is that we can’t change the size of the scissor box while rendering with vertex arrays. So what should we do?

Well, clipping is a somewhat simple 2d operation so we simply clip on the CPU now! The quads we will send into the vertex array will already be clipped so we don’t have to change the scissor state while we’re rendering

Blending

Nifty renders everything with usual alpha transparency blending (glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)) but it can be changed to Multiply (glBlendFunc(GL_DST_COLOR, GL_ZERO)) if necessary for rendering special effects. However, for the optimized renderer this is a slight problem since we can’t change the blending mode while rendering a vertex array. What Nifty will do now is to create a new batch when the blending mode changes. Since the Multiply blending mode is currently the only “other” blend mode supported and this is rarely used we’ll get away with the new batch approach. Rendering a couple of batches per frame is still a lot better than rendering hundreds of individual quads with hundreds of draw calls.

So with blending out of the way we’ve actually solved all of the problems we set out to fix!

The only thing we have to discuss is how all of this has been implemented.

Usually this is done by each rendering system individually like a LWJGL, JOGL or JME3 batched renderer implementation. However each of these individual implementations would solve the exact same problems outlined above. All of the batching, texture atlas management and so on. Not a very nifty solution.

A better approach would be to solve the managment of the batches once and then use a simplified implementation for the native implementations. And that’s exactly what we did

Unified batched RenderDevice implementation!

Nifty 1.3.3 will provide a default implementation of the RenderDevice interface. The de.lessvoid.nifty.batch.BatchRenderDevice handles all of things we’ve mentioned so far including all of the texture packing logic and so on.

Of course there is still the need for specific implementations to connect all of this to LWJGL, JOGL or jME. But these implementations are now much simpler since they don’t have to handle all of the details the original RenderDevice has to. The de.lessvoid.nifty.batch.spi.BatchRenderBackend SPI is much simpler. The BatchRenderBackend will receive quads that it should buffer in whatever way it sees fit. The LWJGL implementation fills a vertex array exactly as we’ve described above. Handling the texture atlas is reduced to creating a texture and replacing subtextures.

Rendering fonts is also handled inside the BatchRenderDevice which means the BatchRenderBackend doesn’t have to implement that. Font rendering is reduced to rendering quads as well and the font texture is simply treated as another part of the texture atlas. This has the additional benefit that font rendering looks the same no matter what rendering system you use because things like kerning, text string width calculations and so on are all happening inside of Nifty now

But wait, there is even more!

Bonus: LWJGL OpenGL Core Profile implementation

Until this point you could not really use Nifty with modern OpenGL because the original LWJGL implementation didn’t support it. With the new BatchRenderDevice a full OpenGL Core Profile implementation is now available!

Shut up and take my money show me how to use it

Usage of the batched renderer is very easy. In place of your usual RenderDevice implementation you use the BatchRendererDevice when you instantiante Nifty:

BatchRenderDevice renderDevice = new BatchRenderDevice(
    put-in-batched-renderer-backend-here, // BatchRenderBackend impl
    2048, // width of texture atlas
    2048); // height of texture atlas

The first parameter is an implementation of the de.lessvoid.nifty.batch.spi.BatchRenderBackend interface that connects the batched renderer to a specific OpenGL implementation. Currently the following implementations exist:

• LWJGL legacy batched renderer: de.lessvoid.nifty.renderer.lwjgl.render.batch.LwjglBatchRenderBackend
• LWJGL core profile batched renderer: de.lessvoid.nifty.renderer.lwjgl.render.batch.LwjglBatchRenderBackendCoreProfile
• jme3 batched renderer implementation: com.jme3.niftygui.JmeBatchRenderBackend

You’ll need to use Nifty 1.3.3 or Nifty 1.4 nightly builds to have these new implementations available. For jme3 you’ll need a nightly build as well.

Besides the BatchRendererBackend implementation you’ll need to provide the size of the texture atlas as parameters. As mentioned above a 2k texture was enough to run all of Niftys standard examples.

So, that’s all there is!

If you made it through this huge post. Congratulations! You now know all the things that took me a couple of months to figure out

I hope you’ve enjoyed this in-depth explanation a bit!

See you next time!

void

So here is Ben explaining a proper way to configure Nifty logging:

It seems that most people who have issues with Nifty’s logs want to cut down on the number shown, but I, on the other hand, wanted to see more. Unfortunately, setting the global logging level to Info caused JME3 to also log lots of information that wasn’t relevant to the problem at hand. I attempted a quick fix using the following code:

public static void main(String[] args) {
        Logger.getLogger("").setLevel(Level.WARNING);
        Logger.getLogger("de.lessvoid.nifty").setLevel(Level.INFO);
        SimpleApplication app = new SimpleApplication() {
            public void simpleInitApp() {
                NiftyJmeDisplay niftyDisplay = new NiftyJmeDisplay(
                     assetManager, inputManager, audioRenderer, guiViewPort);
                Nifty nifty = niftyDisplay.getNifty();
                nifty.loadStyleFile("nifty-default-styles.xml");
                nifty.loadControlFile("nifty-default-controls.xml");
                guiViewPort.addProcessor(niftyDisplay);
            }
        };
        app.start();
    }

However, you’ll quickly realise that this doesn’t actually cause Nifty to display any extra logs. After many hours trying to work out why, I discovered that it’s all down to an intricacy in the way LogManager keeps track of the Loggers in your program. LogManager only keeps a weakReference to each Logger, allowing any that are no longer being used to be garbage collected. Because of this, in the time between line 3 and line 6, the JRE garbage collects the original “de.lessvoid.nifty” Logger created at line 3. When the “de.lessvoid.nifty.Nifty” Logger is retrieved in the Nifty constructor (called by the NiftyJmeDisplay constructor at line 6), a new one is created and it inherits its Level from the rootLogger, which is set to Warning at line 2. (The LogManager keeps a strong reference to the rootLogger so it is never garbage collected.)

A quick (but not very nifty) solution to this problem is to just keep a static (strong) reference to the “de.lessvoid.nifty” Logger in your class, as such:

    private static Logger logger;

    public static void main(String[] args) {
        Logger.getLogger("").setLevel(Level.WARNING);
        logger = Logger.getLogger("de.lessvoid.nifty");
        logger.setLevel(Level.INFO);
        SimpleApplication app = new SimpleApplication() {
            public void simpleInitApp() {
                ...
            }
        };
        app.start();
    }

Ultimately though, the niftiest solution to this problem is to use a custom properties file which specifies to the LogManager how to initialize all of the Loggers. The following “logging.properties” file will initialize the Logging system in the same way as the code above:

handlers=java.util.logging.ConsoleHandler
.level=WARNING
de.lessvoid.nifty.level=INFO

There are two ways to tell the LogManager to use this file. Either use the

"-Djava.util.logging.config.file=pathToLogging.properties"

flag when running your program, or, alternatively, use the following code:

    public static void main(String[] args) throws Exception {
        InputStream inputStream =
             ClassLoader.getSystemResourceAsStream("logging.properties");
        LogManager.getLogManager().readConfiguration(inputStream);
        SimpleApplication app = new SimpleApplication() {
            public void simpleInitApp() {
                ...
            }
        };
        app.start();
    }

Hopefully this should help anyone who comes across the same issue that I did!

(As a small side note, there is one final alternative: LogManager can also use the “java.util.logging.config.class” property. If present, the given class will be loaded, an object will be instantiated, and that object’s constructor is responsible for providing the initial configuration as an InputStream, just as above.)

So that’s it! Finally you can configure logging correctly! THANKS A LOT BEN!

void

PS: Nifty 1.3.3 and Nifty 1.4 have already been configured to log less by default. So most people should now be more happy with the new defaults. But if you really need the logging to debug an issue you now can do it properly – thanks to Ben

Well, I was wrong.

To achieve a somewhat high performance you still have to play by the GPU rules. Simply throwing polys at the GPU and expect the best rendering performance doesn’t really work. In this two part series of blog posts I’ll try to explain what basically sucks in the current way we render things and what we’ve done in the last couple of months to achieve better rendering performance.

There is of course always room for more improvement. One thing I’d like to tackle in the future and especially in Nifty 2.0 would be to render only the parts of a scene that have changed. Since the best performance you can ever get is not to render But since this is a bit more involved for now we’re stuck with the “render the whole GUI each frame” approach of current generation Nifty. BUT at least we can make Nifty render fast. Very fast.

So here we go. A trip down the current way how Nifty renders its GUI and how we can try to be a bit smart to optimize it a lot. In this first part we’ll look at the way the current renderer works and how bad some of the decisions have been according to rendering performance. In the second part of this two part series we’ll look at the way we can make everything better and speed it up.

When it comes to rendering Nifty only knows three somewhat high level primitives:

• render a quad in a single color or with different colors at each vertex (for gradient support)
• render a textured image
• render text with a given font

So all of the elements on your Nifty screen and all effects you apply to them will end up as a number of colored quads, textured images or text renderings.

To actually perform all of this Nifty provides some SPI in the de.lessvoid.nifty.spi.render package. If you implement the four simple interfaces for the rendering system of your choice you’re done and Nifty can be used with your rendering system. Nifty provides native LWJGL, JOGL, jME3, Slick2D and even Java2D adapter implementations already.

So let’s take a look at the main interface of the SPI the de.lessvoid.nifty.spi.render.RenderDevice. There are methods to load images and fonts and methods to let Nifty request the size of the screen. Other methods let the implementation know when a render frame begins and when it ends. However, the core of the RenderDevice interface are a couple of methods to render colored quads, images and text.

The render*() methods contain almost all the state that is required to perform the render directly as method parameters. Things like where to render the quad on the screen and which width, height and color to use are given as parameters.

Besides those parameters there are two additional states that can be modified by Nifty in calling RenderDevice methods which are:

• the current blendmode – that defines how blending should be configured prior to rendering elements
• enable or disable clipping – to restrict rendering to a certain rectangle on the screen. Everything outside this clipping rectangle will not be rendered.

So Nifty calls beginFrame() and then repeats for everything it needs to render: set the state (clipping and blending) and then calls renderQuad(), renderImage() or renderFont() and finally it calls endFrame(). In each render*() call the implementation will now ensure that the correct textures are set or that texturing is disabled, to render plain colored quads. In case of font rendering the correct bitmap font texture needs to be selected so that the text can be rendered properly and so on.

And here is the main issue in the naive implementations that have been used so far especially in the LWJGL renderer. Changing state costs performance since each state switch results in quite a lot of processing on it’s way through all the different layers involved on the way to the GPU. There are driver calls, OS calls, state checks, command queues and so on to finally set the GPU in the state we need to render our triangles. If you’re interessted in all of the details there is a great series of blogs available by Fabian Giesen called A trip through the Graphics Pipeline 2011.

So the first issue the current way Nifty renders stuff is that we change state quite a lot each frame. If we need to render a single colored untextured quad we’ll need to disable texturing. If we need to render a certain image next, we’ll need to enable texturing again and make sure the texture of the image we need to render is enabled. The same happens to clipping and blending which need to be enabled or disabled as well. So we’re constantly changing state which, well, hurts performance.

A second issue that is especially apparent in the native LWJGL renderer is the way the actual vertex data is submitted to the GPU. When submitting data to OpenGL the classic (and very old way) to submit vertex data has been used: the immediate mode. Which means each vertex is send with multiple OpenGL calls. Here is an example:

// code to render a single quad with vertex color - DON'T DO THAT!
  GL11.glBegin(GL11.GL_QUADS);
      GL11.glColor4f(topLeft.getRed(), topLeft.getGreen(), topLeft.getBlue(), topLeft.getAlpha());
      GL11.glVertex2i(x, y);
      GL11.glColor4f(topRight.getRed(), topRight.getGreen(), topRight.getBlue(), topRight.getAlpha());
      GL11.glVertex2i(x + width, y);
      GL11.glColor4f(bottomRight.getRed(), bottomRight.getGreen(), bottomRight.getBlue(), bottomRight.getAlpha());
      GL11.glVertex2i(x + width, y + height);
      GL11.glColor4f(bottomLeft.getRed(), bottomLeft.getGreen(), bottomLeft.getBlue(), bottomLeft.getAlpha());
      GL11.glVertex2i(x, y + height);
    GL11.glEnd();

That’s really bad. First there are lots of calls to the GL and each of the calls will need to get through the different layers and checks again. This will only be ok if you send very view vertices but as the vertex count increases the overhead of the individual method calls will add up and will hurt performance as well.

So these are the main issues we’ll need to solve to improve rendering performance:

• reduce state switches
• reduce draw calls to send vertex data

The second part of this mini blog series will explain how we solve those two issues by providing a special RenderDevice implementation. Interesting enough this special RenderDevice solves additional issues and makes implementing a new renderer for Nifty more easy as well

Instead of hundreds of glVertex() calls we can render the whole GUI in very few draw calls and most of the time even only in a single one! And all of this with no changes to the rest of Nifty or your code. In most case you’ll be able to use the new special RenderDevice for a performance boost and that’s it. nifty!

Curious? See you on the next blog post!

void

Nifty GUI Manual 1.3.2

The changes are marked in the document but here is a summary of everthing that has been added:

• Grammar and spelling corrections thanks to wezrule
• Get Nifty Version String Feature Description
• (Short) description of imageMode=”subImageDirect:x,y,w,h” Feature
• Padding feature description including lots of examples with screenshots
• Margin feature description
• Renderorder feature description
• Nifty event consuming and disable flags description
• Description of general mouse event processing changes in Nifty 1.3.2
• Dynamically changing effect parameters example

void

http://niftyguieditor.altervista.org/

It’s a Java Swing application that uses the Nifty Java2D renderer for preview. This means you can change Element properties and see the changes in realtime! Pretty, erm, Nifty!

There are a lot of people worth mentioning here that have helped in Niftys development in one way or another, be it forum posts, comments, bug reports or emails. Actually there are countless people and I’d not be able to list them all! But all of that feedback – may it positive or negative – is greatly appreciated! Keep it coming and thanks A LOT for it!

This time I’d really like to mention a couple of special people that have provided direct patches and pull requests for Nifty 1.3.2. First of all there is:

Martin Karing (nitram) of http://illarion.org/

who provided countless suggestions and patches. He rewrote the Slick2D renderer and pretty much rewrote the Tabs control to make it actually usable. So extra special kudos go out to Martin!

Other Nifty 1.3.2 contributors I’d like to thank for improving Nifty are – in alpabetical order:

Jeremy Woertink / jwoertink
Joachim Durchholz / toolforger
Jonathan Fischer Friberg / odyssomay
Mark / ractoc
Tony Ivanov / telamohn

Thank you all. You rock! And see you all in Nifty 2.0! =D

void

There will be an updated Nifty Manual available soon. Until it is available you can find out what’s new in the Nifty 1.3.2 change log (sf.net)

And here are the other Nifty links:

Nifty 1.3.2 Download Folder at sf.net
Nifty 1.3.2 Maven Projects Page (browse the JavaDoc online!)
Get a nightly jME3 build with Nifty 1.3.2 (jME3_2012-10-08.zip+)
Webstart – Nifty Default Controls Example (1.3.2)
Webstart – Nifty Standard Examples (1.3.2)

For Maven simply add our sf.net Nifty Maven Repo to your pom.xml:

  
    
      nifty-maven-repo.sourceforge.net
      http://nifty-gui.sourceforge.net/nifty-maven-repo
    
  

and upgrade your dependency to 1.3.2:

    
      lessvoid
      nifty
      1.3.2
    

Have a lot of fun with Nifty 1.3.2! The best Nifty since Nifty
void

package some.test;

import java.util.logging.Logger;

public class Main {
  private static Logger log = Logger.getLogger(Main.class.getName());

  public static void main(final String[] args) {
    log.info("test");
  }
}

This works well and you get something like this as the log output:

01.04.2012 19:10:39 some.test.Main main
INFO: test

Now we can easily change the configuration of this logger and change the Loglevel. So for instance when we don’t like any logging we can disable logging for this class either using a configuration file or do it directly from code like so:

Logger.getLogger("some.test").setLevel(Level.OFF);

and the class will not log anymore.

Sometimes doing this in Nifty and using the name “de.lessvoid.nifty” for instance to shut off the logging refused to work. Some classes simply didn’t stop logging at all. What’s going on?

After a long headache we’ve finally found out!

Nifty used some special logger names for eventbus and inputevent logging. Both loggers used special names that did not relate to any class because there where several classes that would need to log those events. So a special name, like “NiftyEventBusLog” made sense for me.

In some places we had code like that:

package some.test;

import java.util.logging.Logger;

public class Main {
  private static Logger differentLog = Logger.getLogger("SpecialLog");

  public static void main(final String[] args) {
    differentLog.info("test");
  }
}

I somehow expected the loggername in the log to be “SpecialLog” since it’s the name of the logger. But in fact we get something else:

01.04.2012 19:24:41 some.test.Main main
INFO: test

O_o

The information still shows “some.test.Main” since this is the class that actually logged!

If you now try to disable logging for this class, like we’ve seen above:

Logger.getLogger("some.test").setLevel(Level.OFF);

YOU WOULD STILL SEE THE LINE IN THE LOG – even though you’ve disabled it (kinda)

Of course to fix this you would need to disable the “SpecialLog” additionaly to “some.test.Main” but that’s pretty odd since you usually don’t know the exact names of all loggers beforehand.

So to make a long story short Nifty now (current git) removed all the special loggers and always only uses the logger with the name of the current class. When you now disable a logger you should be pretty sure that you really disable any output with that name

void

EDIT

I just realized that it would be very helpful to give you the actual logger names you need to disable when you still use Nifty 1.3.1:

• “NiftyInputEventHandlingLog”
• “NiftyEventBusLog”
• “NiftyImageManager”

Nifty Default Controls Example (1.3.1)

Nifty Standard Examples (1.3.1)

Have fun,
void

There are now two main development branches available:

1.3
The branch formerly known as 1.3.1. This branch will be the base for an eventual 1.3.2 release. Mostly bugfixes should go in there but maybe some improvements will find their way into this as well.

master
The main branch and the base for any 1.4 development. This will be an unstable version (1.4.0-SNAPSHOT) for a while but all the new nifty things will be in there.

While speaking of 1.4 there is not yet a final plan for it. We’ll need to sort out all of the bug and feature requests first. Please feel free to suggest other things you’d like to see in the comments or on the forum.

Both branches are available at sf.net and at github. Synchronizing both repos is a manual process at the moment but works pretty good thanks to git!

Ah and one final word about the git repository at sf.net: Unfortunately the sf.net “code / git” menu lists the wrong repository. I’ve talked to their tech support on IRC and this can’t be changed at the moment :/

The “develop” menu has the correct URL which is:

git clone git://nifty-gui.git.sourceforge.net/gitroot/nifty-gui/nifty

So the correct URL ends with “nifty” and not with “nifty-gui”! Sorry about this =)

void