I'm using JOGL (jogamp) and want to drive the animation from my own thread. The tutorial I ran into shows using Animator or FPSAnimator, but those have their own threads and I want to avoid that.
This is because I'm doing various other thread management and such and so I already have a thread that knows when computation results are ready to push the next frame to the GPU.
Is this possible? Or is it just a really bad idea?
It appears the answer is to directly call display on the GLWindow:
http://jogamp.org/deployment/v2.1.2/javadoc/jogl/javadoc/com/jogamp/newt/opengl/GLWindow.html#display()
Related
I have two threads running in my program. When I try to use OpenGL functions in the thread that is not my main, it throws an IllegalStateException:No OpenGL context is current in the current thread. So my question is, how do I pass the context from the main thread to a different thread? I am using LWJGL 3.
I think I solved it but I'm not 100% sure it's the best way to do it. You have to call GLFW.glfwMakeContextCurrent(MemoryUtil.NULL); in the thread you want to depart from, then call GLFW.glfwMakeContextCurrent(window); GLContext.createFromCurrent(); from the thread you want to switch to.
Take a look at this example. It uses a Drawable that you can use in your two Java Threads. I'm not entirely sure if it still works since a lot of this class is associated with LWJGL 2. I'll test it soon and let you know if this or your method is more efficient (Gonna create a tiny micro-benchmark :) .
I have a GUI and the GUI is starting another thread (Java). This thread is starting a class which is crawling many websites. Now I want to show in the GUI how many websites are crawled and how many are left.
I wonder what's the best solution for that.
First idea was to start a timer in the GUI and periodically ask the crawler how many is left. But I guess this is quite dirty...
Then one could pass the GUI to the crawler and it is calling a GUI method every time the count of ready websites changes. But I don't think that's much better?
What is the best way to do something like that?
It depends.
Ask the crawler how much work it is done isn't a bad idea. The benefit is you can actually control when an update occurs and can balance out the load.
The downside is that the information may go stale very quickly and you may never get accurate results, as by the time you've read the values, the crawler may have already changed them.
You could have the crawler provide a call back interface, which the GUI registers to and when the crawler updates it's states, calls back to the GUI.
The problem here is the UI may become swamped with results, causing to lag as it tries to keep up. Equally, while the crawler is firing these notifications, it isn't doing it's work...
(Assuming Swing)
In either case, you need to make sure that any ideas you make to the UI are made from within the Event Dispatching Thread. This means if you use the callback method, the updates coming back will come from the crawlers thread context. You will need to resync these with the EDT.
In this case you could simply use a SwingWorker which provides mechanisms for syncing updates back to the EDT for you.
Check out Concurrency in Swing for more details
register a callback function to your thread. when your data is dirty, invoke this callback function to notify GUI thread to update. don't forget to use synchronization.
I was wondering how I would use multiple threads in an applet at the same time. I'm creating a game like Space Invaders and I wrote all the code for the enemies to move and shoot but I can't add the player in to move around using the keyboard at the same time as the enemies. So I was thinking I needed to have 2 different threads running. I would upload the code but there is a lot of different classes and code.
If someone could help me out quick I would appreciate it a lot.
Yes they are independant of each other i got my single thread that moves the enemies in the run() method that i overloaded and all my movements are in the paint method.
should they be somewhere else?
You can do this with one thread, or with two.
Either way you have to work with the GUI Event Thread to do all the screen updates.
There is a lot of reference on the web discussing how to do this. If you google java space invaders you get 1.5 million hits and usually the first page of such a search has more than what you need.
I think the enemies are independent and have particular movements, if that's the case, you will need several threads enemy, and for each player, but taking into account the resources of the computer you should deal with a manager thread or task managers.
These are links that maybe help you.
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/CyclicBarrier.html
I've just developed an app for Android, it is a game but i'm not using 3D graphics. It's a board game where i move ImageViews around on the screen. Since now I haven't yet tested it on a mobile device, just on the emulator. The problem is that when i run my app on a Samsung Galaxy S2 phone (dual ore :( ), the CPU Usage goes up to 85% and the damn phone heats up :D when i kill the process (close the app entirely, so it doesn't run in the background) it goes down to 0 :)
I don't even know where to start fixing the problem. Could you guys give me an idea?
I can only think of two reasons for which this might happen, but they might be stupid reasons:
With the exception of the UI thread, I have 2 more threads, each having an infinite while loop which cycles indefinite and looks if there are any messages in the message queue of each thread. Could this be the case? Should i put a delay in these loops of a couple of milliseconds, so they don't run so fast?
I'm also using around 20-25 imageViews on the screen which i'm moving around with via touch. Could those have anything to do with this?
Is there a way to check for memory leaks or SOMETHING ... from the emulator?
If anyone can offer some advice on how i should approach this issue, i'd be grateful.
"I have 2 more threads, each having an infinite while loop which
cycles indefinite and looks if there are any messages in the message
queue of each thread"
The above thing sounds suspicious to me. Instead of using infinite loop in your own thread, you should really make use of Handler which is designed exactly for this purpose.
As from developer's site:
A Handler allows you to send and process Message and Runnable objects
associated with a thread's MessageQueue. Each Handler instance is
associated with a single thread and that thread's message queue.
There are two main uses for a Handler:
to schedule messages and runnables to be executed as some point in
the future
to enqueue an action to be performed on a different thread than your
own
Besides, DDMS tab in Eclipse would give you all the required tools to investigate the excess use of CPU.
The scenario is this: I have Java swing application with JFrame. There is textarea where you can type things, then you get the search results in another textarea and when you select one of the results, there is a button "Download". And here comes the problem. When you hit "Download" the application should display information about the completness of the downloaded files. I've do this with a class extending Thread called DownloadManager which updates the information on a period of time. However I'm concerned that there may be problems with synchronization. Is there a standard way to update such dynamic info without threads? Is there a mainloop or something like this in Java swing classes. How do you do it?
Have a look at SwingWorker:
http://download.oracle.com/javase/6/docs/api/javax/swing/SwingWorker.html
There may be better ways but that's what I used for my progress bar when downloading things and updating progress bars.
Anything that updates the GUI in Java should be done by the GUI event dispatch thread. To force a method to be run in this thread, you need to use the SwingUtilities.invokeLater. Doing anything else could potentially cause your GUI to hang, not update, or other strangeness!
This is a good tutorial that describes it better than I did:
http://www.javamex.com/tutorials/threads/invokelater.shtml
No there are not so much problems with synchronization. If working with background threads in Swing consider to use a SwingWorker.