nifty-gui

Inside Niftys RenderDevice and how to speed it up (Part 2/2)

// April 1st, 2013 // 4 Comments » // design

Welcome back to the second part of this two part mini series. Today we’ll speed up the Nifty rendering process. So fasten your seat belts – it will be a long and rough ride!

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.
Continue Reading

Correctly configure jdk14-logging (guest blog post by Ben)

// March 16th, 2013 // 1 Comment » // Uncategorized

After being puzzled for a while why he wasn’t able to configure logging in jME-Nifty properly Ben (“ben dot foxmoore at gmail dot com”) set aside some time to figure it out. He was kind enough to share his findings with us in this guest blog post

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

Inside Niftys RenderDevice and how to speed it up (Part 1/2)

// March 10th, 2013 // 6 Comments » // design

When I started Nifty my mindset was like, “well, games can render millions of polys each frame so throwing a couple of hundred textured polys at the GPU shouldn’t hurt performance that much”.

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.
Continue Reading

Updated Manual for Nifty GUI 1.3.2 available

// November 12th, 2012 // 2 Comments » // docs

The updated Manual for Nifty GUI 1.3.2 is now available as a sf.net file download: nifty-gui-the-manual-1.3.2.pdf

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

Nifty GUI Editor Project

// November 8th, 2012 // 1 Comment » // sightings

There is a Nifty editor project started by Cristiano Aguzzi which looks very promising. It allows you to create Nifty GUI XML by simply adding Nifty Elements and Controls with drag’n'drop!

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!

Nifty 1.3.2 contributors kudos

// October 10th, 2012 // 2 Comments » // Uncategorized

Well, this was really planned to be a part of yesterdays release announcement but somehow I missed to include it :/

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

Nifty 1.3.2 finally arrived

// October 8th, 2012 // 10 Comments » // release

Nifty 1.3.2 is mainly a bugfix release and is compatible with Nifty 1.3.1. There are a couple of nifty new features available too We’ve counted 175 individual changes which is A LOT!

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

java.util.logging (jdk14 logging) oddities explained (and fixed)

// April 1st, 2012 // 17 Comments » // bubble, design

Usually when you add logging to your application you create a java.util.logging.Logger that has the same name as the class you use the Logger in. Your code might look like this:

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 1.3.1 webstart demos online

// January 15th, 2012 // 6 Comments » // demo

In case you’ve missed the online demos with the latest Nifty 1.3.1 release (like Nifty user waltobc6) this might be of interest for you:

Nifty Default Controls Example (1.3.1)

Nifty Standard Examples (1.3.1)

Have fun,
void

scm branch cleanup

// January 14th, 2012 // 3 Comments » // Uncategorized

So now that 1.3.1 is out of the way, we’ve cleaned up the branches in git.

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