I noticed that recently when I run my LibGDX game it takes a good 20 seconds to boot up which is strange because I'm only loading a few resources. I put breakpoints in my main method to pinpoint where the app was getting stuck, and it turns out it's getting stuck when I call this line:
new Lwjgl3Application(new GdxGame(), config);
In the Lwjgl3Application constructor, it is hanging on this method call:
initializeGlfw();
Which looks like this:
static void initializeGlfw() {
if (errorCallback == null) {
Lwjgl3NativesLoader.load();
errorCallback = GLFWErrorCallback.createPrint(System.err);
GLFW.glfwSetErrorCallback(errorCallback);
if (!GLFW.glfwInit()) {
throw new GdxRuntimeException("Unable to initialize GLFW");
}
}
}
In this method it gets stuck on createPrint and GLFW.glfwInit(). The print method looks like this:
public static GLFWErrorCallback createPrint(PrintStream stream) {
return new GLFWErrorCallback() {
private Map<Integer, String> ERROR_CODES = APIUtil.apiClassTokens((field, value) -> 0x10000 < value && value < 0x20000, null, GLFW.class);
#Override
public void invoke(int error, long description) {
String msg = getDescription(description);
stream.printf("[LWJGL] %s error\n", ERROR_CODES.get(error));
stream.println("\tDescription : " + msg);
stream.println("\tStacktrace :");
StackTraceElement[] stack = Thread.currentThread().getStackTrace();
for ( int i = 4; i < stack.length; i++ ) {
stream.print("\t\t");
stream.println(stack[i].toString());
}
}
};
}
All of these methods come from the Lwjgl library. Does anybody know why my app might be getting stuck on these method calls?
I've had the same issue and it seams to be tied to the machine you are on. I made a clean VS15 solution with GLFW and ran it on several different PCs to find that only my desktop had this issue. I also tested the LWJGL binding of GLFW and had the same results.
[EDIT] the wait happens in the glfwInit() call
/* Initialize the library */
if (!glfwInit()) // stuck here
return -1;
/* Create a windowed mode window and its OpenGL context */
window = glfwCreateWindow(1920, 1080, "Hello World", NULL, NULL);
There is one post that I came across an archived post on the openGL forums that mentions an issue similar to this but it's fairly old and might be referring to a slightly different issue.
I can recommend to check that you are excluding your build folder from any antivirus, sometimes they see the generated executables as potential threats and thus might be slow however i dont believe that's your issue.
Sadly the only option that has worked for me was a clean install of windows, though the bug mysteriously stopped manifesting itself when I connected a VR headset and reappeared a couple days later. Hope you have better luck than me and dont have to clean install your OS and if you find a less cumbersome solution be sure to spread the word.
Related
I'm using a JOGL FPSAnimator and Apple's FullScreenUtilies class. I implemented this some time ago, and it worked fine. Here is my code for enabling the native OS X fullscreen capability, similar to other code on SO and around the web:
String className = "com.apple.eawt.FullScreenUtilities";
String methodName = "setWindowCanFullScreen";
try {
Class<?> clazz = Class.forName(className);
Method method = clazz.getMethod(methodName,
new Class<?>[] { Window.class, boolean.class });
method.invoke(null, frame, true);
} catch ...
It also works fine in the context of a simple test program I made in an attempt to isolate the issue. I'm not sure at what point the behaviour changed - I haven't spotted anything incriminating in SVN logs. It's likely that I first implemented the feature on an earlier version of OS X, and have also upgraded JOGL version and MyDoggy which we use for docking since. However, all of these things work with fullscreen in the context of other applications.
When I press the green fullscreen button, the usual OSX fullscreen transition starts (it gets its own desktop space), but the window appears frozen from that point on.
The main AWT Event thread carries on running, and I can see that my GLEventListener.display() method is being regularly called. I've tried adding a return to the beginning of that method to eliminate the impact of my rendering code, this unsurprisingly made no difference.
For testing purposes, I added a FullScreenListener:
FullScreenUtilities.addFullScreenListenerTo(frame, new FullScreenAdapter() {
#Override
public void windowEnteringFullScreen(FullScreenEvent arg0) {
log(">>> Entering fullscreen... <<<");
}
#Override
public void windowEnteredFullScreen(FullScreenEvent arg0) {
log(">>> Entered fullscreen. <<<");
}
});
As anticipated, I get the entering fullscreen event, but not the entered one.
It's a fairly large program, but there should be a fairly small surface of things that are potentially relevant here... unfortunately I haven't managed to trace them down. Happy if anyone has any pointers.
I'm aware that JavaFX has it's own media player, but I do not know if it can play MP4 files.
Even if it could, I would still prefer to use VLCJ as VLC supports more formats and varieties than I can count in my near-catatonic state.
I've followed the example posted by Caprical in his VLCJ-JavaFX GitHub but it does, well, nothing.
It doesn't error, but it does nothing.
Looking into the code, it seems the issue is in the Timeline event handler:
private final EventHandler<ActionEvent> nextFrame = new EventHandler<ActionEvent>() {
#Override
public void handle(ActionEvent t) {
Memory[] nativeBuffers = mediaPlayerComponent.getMediaPlayer().lock();
if (nativeBuffers != null) { //<-----This is always NULL so everything in the block is skipped . . .
// FIXME there may be more efficient ways to do this...
// Since this is now being called by a specific rendering time, independent of the native video callbacks being
// invoked, some more defensive conditional checks are needed
Memory nativeBuffer = nativeBuffers[0];
if (nativeBuffer != null) {
ByteBuffer byteBuffer = nativeBuffer.getByteBuffer(0, nativeBuffer.size());
BufferFormat bufferFormat = ((DefaultDirectMediaPlayer) mediaPlayerComponent.getMediaPlayer()).getBufferFormat();
if (bufferFormat.getWidth() > 0 && bufferFormat.getHeight() > 0) {
pixelWriter.setPixels(0, 0, bufferFormat.getWidth(), bufferFormat.getHeight(), pixelFormat, byteBuffer, bufferFormat.getPitches()[0]);
}
}
}
mediaPlayerComponent.getMediaPlayer().unlock();
};
};
It's been suggested I get the logs but that will have to wait as I'm slipping into unconsciousness as I make this post (when I return to the land of the living, I will see about what I can do to post some). If there is a better way to make this happen, I'm all for it if someone can direct me there. Thanks...
The vlcj-javafx sample on the Github project works just fine.
You say in your question that vlcj "doesn't error, but it does nothing".
Well, there are two ways to check for errors which you don't show in the code you posted in your question.
The mediaPlayer.playMedia() method returns a boolean to say whether VLC accepted your MRL or not - did you check the return value? Note that even if this method returns true, it does not categorically mean VLC could play your media, but if it returns false it categorically means it could not be played.
You should add a MediaPlayerEventLister to your media player and provide implementations for "playing()" and "error()". These callbacks will be triggered asynchronously - because that's how LibVLC works - only then can you conclude whether vlcj "doesn't error", or "does nothing".
I suspect your media failed to start, probably because of a wrong filename.
I did this program that opens multiple link with default browser:
ArrayList<String> linkList = new ArrayList<>();
for (int i = 0; i < linkList.size(); i++) {
ClassRunnable_OpenLink obj = new ClassRunnable_OpenLink ( linkList.get(i) );
Thread thread = new Thread(obj);
thread.start();
}
private class ClassRunnable_OpenLink implements Runnable {
private URL link;
private String string;
public ClassRunnable_OpenLink (String string) {
this.string = string;
}
private void OpenWithBrowser () {
try {
link = new URL ( string );
edu.stanford.ejalbert.BrowserLauncher launcher = null;
try {
launcher = new BrowserLauncher(null);
} catch ( BrowserLaunchingInitializingException | UnsupportedOperatingSystemException ex) { }
launcher.openURLinBrowser( link );
} catch ( MalformedURLException ex | IOException | URISyntaxException ex) { }
}
#Override
public void run() {
OpenWithBrowser( );
}
}
This works great only if browser (say it's firefox) is already opened, but if it's not, my program only opens the first link and then I have a firefox message that tells me the the browser is still running so I need to close it first.
Same thing with chromium.
So I thought, if I had a way to check when the browser is closed I could use ProcessBuilder to open new firefox process, but I don't know if it's the best way to do this. Besides my java program allows user to select default browser so it could be complicated to use ProcessBuilder in that case.
So do you a have any idea to solve my problem? Maybe I could set a delay between each Thread in this way the system has the time to execute browser process first time, then opening first link and after the browser is running, opening other links, but how about the delay time in seconds? I'm not able to know the time that browser needs to open so it's not a good idea.
I hope you can help me. Thanks
Since java 6 you don't have to use 3rd party implementations to open a webpage with the standard browser. Try
java.awt.Desktop.getDesktop().browse(uri);
Since this maps to the underlying OS functions chances are high multiple calls will work as expected.
A workaround to this (without knowing your exact expectations), could be to do the following:
After first URL open, you could build a delay of for example 10 seconds.
Then in any consecutive URL openings, you can assume that the browser is now surely open, and start opening the next URL's fast after each other.
One note though: Always add some delay to opening URL's (not sure if your framework already does this), because else the browser might crash from the number of URL openings.
UPDATE: You say that Thread.sleep() causes your program to block, this should never happen.
You should always seperate long-during actions from the rest of your program (The (Graphical) User Interface).
So it would be better to write your 'URL opener facility' in another thread.
You can read more about that here: http://docs.oracle.com/javase/tutorial/essential/concurrency/
The macify Notepad example is the only example of 'macification' I could find, and it's all fine and dandy I guess, apart from the menu which completely screws up my layout.
I'm very, very new at Java so I follow examples like these to the letter, but this menu really has to go.
Is there a way to catch the 'about' stuff without a menu? After all, this about thing on Mac OSes seems to be there even without one. Standard procedure, etc.
I don't have a Mac to test the code, so trial and error is severely limited...
How is this done?
Bit of a necro-post but it's code I use all the time. It's complicated and uses reflection to avoid throwing errors on non-Mac systems, however.
In the initialization of your app or as a static code block:
if (System.getProperty("os.name").contains("Mac")) {
try {
Object app = Class.forName("com.apple.eawt.Application")
.getMethod("getApplication")
.invoke(null);
Object al = Proxy.newProxyInstance(
Class.forName("com.apple.eawt.AboutHandler").getClassLoader(),
new Class[]{Class.forName("com.apple.eawt.AboutHandler")},
new AboutListener()
);
app.getClass()
.getMethod("setAboutHandler", Class.forName("com.apple.eawt.AboutHandler"))
.invoke(app, al);
}
catch (Exception e) {
//fail quietly
}
}
At the bottom of the source file after the last curly brace
public class AboutListener implements InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args) {
//Show About Dialog
return null;
}
}
When releasing a full application in java things like this make nice small touches. This should be mostly copy-and-paste-able but you will need to add a line or two to display an about box. If you need to test really badly use web-start, dropbox public links, and a neighborhood Apple Store.
I'm having trouble getting a short MP3 file to play in a very small app I'm writing to learn how to develop for the BlackBerry.
Because I'm a newbie at BlackBerry development, I've uploaded my Eclipse project for the app to http://stroke.sampablokuper.com/stroke.zip because I don't know if the problem's with my Java programming, or the way I've laid out the resources in my project, or something else.
It's a very small project - only one Java file & three media files - so please help me by seeing if you can run it without errors in the Curve 8520 simulator on your computer. (It's designed for the 8520, because that's the phone a friend of mine has; I don't have a BB myself - yet!)
The idea is that when the user presses/scrolls "down" on the trackball/pad, a sound will be played, but currently instead of the sound, I just get an error message: javax.microedition.media.MediaException .
I've tried to debug this, but as I say, I'm a total newbie to BB development, so I don't really know how to make sense of the information I get from the breakpoints I've set.
Please can you tell me where I've gone wrong?
I really want to finish this before Christmas; please help!
Thanks in advance :)
EDIT: here's the relevant portion of the code, stripped down as much as possible:
public boolean navigationMovement(int dx, int dy, int status, int time) {
if (dx == 0 && dy == 1)// DOWN
{
makeNoise("growl");
}
return true;
}
private void makeNoise(String action) {
if (action == "growl") {
Dialog.alert("GROWL");
try
{
Player p = javax.microedition.media.Manager.createPlayer("growl.mp3");
p.realize();
VolumeControl volume = (VolumeControl)p.getControl("VolumeControl");
volume.setLevel(30);
p.prefetch();
p.start();
}
catch(MediaException me)
{
Dialog.alert(me.toString());
}
catch(IOException ioe)
{
Dialog.alert(ioe.toString());
}
}
invalidate();
}
Further edit I've removed the link to download the project, since the problem did indeed appear to be with the code, and is now solved anyway.
if you have mp3 file on SDCard your URI should be file:///SDCard/<file>.mp3 but if you are playing it from application then getResourceAsStream is the answer
The problem turned out to be that the string passed to the .createPlayer method needs to be a URI.
I tried many variations along the lines file:///growl.mp3 before eventually giving up (if anyone knows the correct URI syntax for pointing to a file within a BlackBerry App, please comment!) and settling on this:
InputStream is = getClass().getResourceAsStream("growl.mp3");
Player p = javax.microedition.media.Manager.createPlayer(is,"audio/mp3");
It's a bit crufty by comparison, but at least it works!