Quote:
a) The example in SlickDesktop doesn't clean the dirty rectangle out after rendering - meaning the dirty rectangle just gets bigger and bigger. (just need to pass the clean flag in as true)
b) The SlickDesktop doesn't perform the same as the JMEDesktop (though this maybe to do with a)
The code in SlickDesktop is as close a match as I could make it to JMEDesktop but there, of course, could be nuances of the code that I missed. I also didn't look too closely at the state, etc. classes from jME as I didn't think it would be overly relevant to getting things on screen in Slick so they could do updates and rendering at different rates to the SlickDesktop example.
Quote:
c) JMEDesktop manages it's own dirty rectangle stuff, mostly well but in several places inefficently (glyph rendering most notable). Swing as a RepaintManager that can handle all this stuff for us - I've used this and seems pretty good.
I'm working on simple tests cases for this stuff which I'll hopefully be able to integrate back in with the SlickDesktop stuf.
I really hope the stuff you're looking at will speed up the drawing, and to be honest, I completely forgot about clearing the dirty rect

. As SlickDesktop currently stands I can't see it being useful for a game GUI. I'm using it for my level editor and other stuff, but I am still looking for something (probably fengGUI) that uses hardware rendering for use in the game.
I would like to be able to use it in my game (after testing with Substance and seeing Nimbus) so I'm hoping that with an extra set of eyes looking at the code you can see something that I missed.
Cheers,
Brett