Vast improvements to SDK editors speed

Hey,



as the SDK matures towards release, I cleaned up some of the dirty corners and the (always dreaded) AWT/OGL threading is now much cleaner, especially in regard to loading scenes. Other things like camera control and update of values in the windows are also much faster because less queueing is needed for the code logic. In tests with the development IDE, normally sized models load up to 5x faster now, theres much less lag when switching camera views or selecting Geometry in the SceneComposer which is about 10x faster now. Switching between files and/or reloading should also work more smoothly.



All in all the switch is quite severe internally, opening Scenes with the TerrainEditor is still broken atm for example, @Sploreg and me are on it. I am quite happy about the results and how quickly the change was implemented in the end though, this frees up a lot of time for the other planned improvements.



Cheers,

Normen

10 Likes

Cool!



Would you layout the things that you would like to improve or add? Like I found you saying in another post that you are going to standardize the editor interaction so writing plugin/ adding editor feature follows own jMP standerd.

Theres a link in the wiki to a filtered googlecode issue viewer: https://wiki.jmonkeyengine.org/legacy/doku.php/sdk#documentation

1 Like

In fact its so quick and solid now, I let the SceneComposer reload the scene when a java file has been saved now (to reflect changes in the ClassPath for the new Custom Controls functionality etc.). The check should be extended in the future though, so its only reloaded when in fact a class that is used in the Scene is changed.

1 Like

thanks thanks thanks thanks thanks :D.

sweeeeeeeeeeeeeetttttt

Should be in the nightly update center now, for some reason it failed to compile this night. Remember the TerrainEditor is still broken though.

1 Like

the NPEs in the terrain editor make is really fast! :roll:

1 Like

xD

very very true! Not only the scene composer, but everything feels super smooth now.



One point though, is it possible to implement any system that automatically submit any crash report of jMP? Its not possible to post every crash log in the forum, but if you insist another “jMP Crash Log” group wont hurt.

Hm, don’t think thats needed.

1 Like

Yes, then that way the people will avoid the forum.

That for one and in fact the “problematic” crashes of jMP are mostly happening at the start or directly on the native java level (lwjgl/direct crash or bail due to graphics or similar) and both cases cannot be caught and then sent. I’m not interested in people forgetting to put the model images in their assets folder :wink:

1 Like

No, i get crash for far more trivial reason. ok, i’ll start posting them from now on, and just say if its needed or not. :slight_smile:


@normen said:
I'm not interested in people forgetting to put the model images in their assets folder ;)


Can this be a reason for a crash?
1 Like

The latest versions are more robust in that respect, they will just put out warnings. But most exceptions I can catch are either known or due to misuse. Just posting the problem with stack trace is good, I’ll then add it to the issues list, fix it or bash you for the misusage :wink:

@normen said:
The latest versions are more robust in that respect, they will just put out warnings. But most exceptions I can catch are either known or due to misuse. Just posting the problem with stack trace is good, I'll then add it to the issues list, fix it or bash you for the misusage ;)


I don't mind if I can learn from it. :D