Develop Reference

Run my code in already existing and running thread

I'm using 3rd party which drawing to a view something.
I got the process threads list and i found the thread they are using to draw their stuff in.
I want to add my drawing code in this thread - meaning when they are finishing drawing their stuff in the thread then my code will run and then the thread will end (or whatever happens with it).
I tried to do my drawing code in different thread and UI Thread but I can see that my drawing is running after the 3rd party when we change the camera position.
Is it possible to inject some code into another thread? btw, I have only their Thread object in my hand which i got from running over all the threads list.
If not, other solution will be fine also (if there is)
-- EDIT --
Tried to suspend their thread, draw my stuff, and resume, but it is crashing - guess due to those are deprecated functions

Purely theoretical stuff ahead:
Check if they support drawing to backbuffer (not screen) -- OR -- try to redirect drawing to a backbuffer(framebuffer). Do your drawing in the backbuffer too. Manually switch backbuffer (actually back framebuffer) with front framebuffer.
They are most probably doing their drawing in a loop. The onDraw may be event triggered or it just tries to provide as much fps as it can. But if you synchronize the access to your backbuffer, you may force their draw thread to wait exactly for the time you do your drawing and the swap of buffers. You need to initially sync your procedure with theirs (probably by painfully testing that your code gets to run from time to time, and drawing is not blocked). And you must remember that if this work, the synchronization will mean that their thread will wait on their N loop for the end of your N-1 loop at exactly the first operation working with the backbuffer.

Avoid RecursiveLockImpl01Unfairish.lock RuntimeException (timeout)?

I have an application that loads a series of large images on startup. This is a Processing application, so most things run on the single main animation thread, and it's using Processing's OpenGL renderer.
EDIT: the RuntimeException is thrown when some process within JOGL takes > 5 seconds. Making it back up the stack to subsequent loadImage() calls means the RuntimeException is avoided. I'm not clear yet how to repro this and so haven't found a way around it save the ugly try-catch + reflection workaround here.
The image loads sometimes take longer than 5 seconds, and when they do, JOGL throws a RuntimeException from within RecursiveLockImpl01Unfairish.lock(). My understanding is that RecursiveLockImpl01Unfairish.lock() complains if the main GL animation thread halts execution for > 5 seconds.
Is there a simple fix for this? I could shift the image loads to a different thread and reshuffle my init sequence to be more asynchronous, but that's a lot of work for something that happens only once, on application init, at a time when the application has plenty of time to start up regardless.
(Note: this is for an installation, no one will be present or trying to use the application when it first launches in the morning, so a delay of many seconds on init is not a problem.)

Can JAI.create() be used in multiple threads?

I'm building a program based on the open source software JPiv, that is used to do digital image correlation and strain analysis. The algorithm in JPiv is, unfortunately, very slow, so I've been trying to use multithreading to decrease the time taken to analyse an image set. The algorithm uses JAI for something, not quite sure what as I've never used it before. When I run it, on the second 'pass', I get a OutOfMemory exception on at least one of the threads, and occasionally get other errors, seemingly at random, but usually IllegalArgument exceptions - sometimes from JAI, sometimes from standard Java libraries. The exceptions get thrown by different libraries at different points in the program, which makes it hard to debug - especially as they don't always give traceback messages in the console, for some reason.
I think the error is in the use of the JAI.create() method, and the way that the different threads access the corr[c] variable to use the above method. Is it possible to use JAI.create() in the way I'm trying to do so?
The code is quite lengthy, so I've put it on Pastebin here: http://pastebin.com/EX92YjXA
Below is a bit of pseudo-code to get a general sense of what I'm attempting.
public doPivEvaluation{
corr = new BufferedImage
start threads
send corr array to threads
loop until threads have finished
do stuff with corr}
public class threads{
on start{
do the analysis using tmpCorr
pb = new ParameterBlock()
pb.removeSources();
pb.removeParameters();
pb.addSource(PivEvaluation.corr[c]);
pb.addSource(tmpCorr);
PivEvaluation.corr[c] = JAI.create("add",pb,null).getAsBufferedImage();
end threads}
Uh, yeah, so maybe not the best pseudo-code ever, but yeah. The position in corr, c, is different for each thread (and refers to a set of pixels, so could be up to 5000 depending on the size of the image, split between the different threads), and corr has been declared volatile, so in theory there should be no overriding of data. Likewise, in theory, if JAI.create() only acts on that position, there should be no problem either. The problem arises because I don't understand how .create() actually works... I know the whole thing works in a single thread, because I've not changed anything of the actual algorithm, only moved it into multiple threads.
Also, apologies for any bad coding practices that may be in the code, I'm relatively new to Java still, so I'm more just muddling along. If I try something and it fixes a problem, I'm likely to go with it even it means multiple variable declarations or whatever other inefficiencies I've made. This is the first problem I've encountered I haven't been able to fix by guesswork and Google.

Is there a more ideal way to send draw commands?

I'm still working on moving my android app over to OpenGL and i'm once again having an issue.
I have gotten to the point where everything FUNCTIONS, the only problem is that the animation seems a little juddery.
I'm monitoring the frame rates and seeing that the drawing thread isn't slowing down, but every once in a while, the main loop slows a bit and I suspect I'm having a problem I was worried about.
The way the app works is that as new objects (say for instance, enemies) are created, 2 objects are actually created. The first one is created and mapped in the main thread, and then in it's constructor, it creates a mesh object which is then added to a group to be drawn continuously by the renderer.
Every time an attribute for the object is changed, (such as its coordinates) The object relays the necessary command to its mesh counterpart (in this example to translate the mesh.)
It was suggested that this was thread safe communication, but i'm having my doubts. I also notice a greater amount of frame skip when new objects are created, I can fix this somewhat by reusing the same mesh object for identical Game objects, but I don't believe this will fix everything by itself.
Can you think of a way to make this more efficient and thread-safe?
Another possible solution: The game logic does not HAVE to go at full speed (realtime) I have it actually set up so that no updates are made untill 33 millis pass. So obviously, I should have plenty of time between frames to draw, can I set it up so that draw is only called on command in the thread (after the game logic has been updated)?

It looks like you need something like a ScheduledThreadPoolExecutor.
With one of these you could put your renderer on a schedule so it executes at 30fps leaving your main/control thread to do whatever it needs to do to the object map between frames.
I don't think you need any wait/notify interlocking as all you really need is to block access to the map while the renderer is walking it. To do this you just need to make the map synchronized. As this will only happen once every 1/30th of a second you are certainly not introducing a significant overhead.
Your main aim should be to put as little unnecessary load on the CPU as possible, this is the key to smooth multithread work. Try to spend as much time as possible either sleeping or blocked.
Added
I subtract the time it took to loop from 33ms, and use the result to specify the length of sleep().
I wonder if that may be part of your issue. On a Windows machine you often get a 15ms resolution on the currentTimeMillis so your sleeps may end up hardly sleeping at all. It may be worth experimenting with a ScheduledThreadPoolExecutor just to see if it improves your timing. ... oops ... this is Android isn't it. Still ... it may be worth a try.

Choppy Image on multithreaded android game

I decided to convert my spritesbased 2d game for android to use opengl-es to help with some render-related framerate issues. Currently the setup is as follows:
Rendering tkaes place in its own thread, with rendermode set to continuous. Game logic updating takes place in a seperate threaad. Both threads interact with a synchronized drawlock class which ensures that they are never touching the game information simultaneously.
So basically, the render thread waits for any current update to finish before drawing and the update thread waits for the current render to end before starting an update. Everything looks great except or some choppiness I've noticed in the picture when moving around the screen.
I believe this is likely due to a lack of consistency in the number of updates that happen in between each render, on average twice as many updates happen because as of right now not a whole lot is happening in the update. But this lacks consistency so sometimes 1 gets through, sometimes 2, 3 etc so the delta in positions of items being drawn is also not consistent thus creating the choppiness.
Anyone have an idea how I might rectify this? The update thread is regulated to 60 times per second with sleeps...maybe something similar needs to happen under render? I'm just not sure at this point.

Depending on how voluminous your game data is, you might try replicating it. While the game engine is updating one copy, the rendering engine is working off the other. When an update is finished, the rendering engine switches to reading the updated copy while the game engine waits until the updates are transferred to the older copy (which the engine will then update on the next cycle). It's kind of a double-buffering approach, but applied to the game data instead of to the display buffer.