I have a requirement where in I need to have two threads of the same process rendering to screen using openGL ES.. I am newbie in android applications and havent done much application development before. I know a bit about openGL ES and I need to test some driver code urgently.
I have two Activity of GLSurfaceView. I use setcontentview and the layout xml file for defining the layout. Each activity has its layout file separately. The size of the rendered displays are small around 10% of the screen and I have made sure that the positions of the display are non-overlapping in the 2 layouts.
Initially one activity is launched which in turn launches the 2nd activity through intent mechanism in the "oncreate".
1) I tried have two activities to run at same time but i have not been successful at that. Some documentation referred that while one activity is running the other activity is possible to be in the visible state. I am not sure whether its possible to have both the activities to be visible at the same time.
2) Initially the implementation was that one activity launches the 2nd activity through intent mechanism in the "oncreate". This resulted in 2 activities running but not simultaneously. Is there a way I can have both activities running simultaneously and displaying.
3) Later for creating the second thread I used the "runnable" mechanism and created a thread and invoked the 2nd activity through the "run" of "runnable". While I could confirm that the thread was confirmed I could not see the 2nd activity running.
4) The constraint is due to the fact that I need to have separate eglCreateWindowSurface for each of the 2 rendering threads.
Are there any sample/examples where I can see how 2 activities or 2 threads are running simultaneusly while displaying to the screen?
I have gone through many tutorials and sample code and discussions to find some hint to my problem. Can someone help with some links or explanations
It is not possible in any version of OpenGL to render to the same render target with two threads. OpenGL is a state driven system so changing the state in one thread will overwrite the state in another thread. There is only a single copy of the OpenGL state as there is only one GPU to process that state.
Related
As I step through my code using F8, after setting a breakpoint, I don't understand how there is code running while the code should be stopped. It is an Android 3D game, and even though the code is stopped, there is a graphics object rotating in the background as if it is in a separate thread from the code that I am debugging or something.
The game code is huge, and there isn't really any point in showing any code, but if there are any specific questions about the code I can either answer it or show some snippet.
Very strange. Any ideas anyone?
[EDIT] I am using Java and Opengl ES 2.0. No third party software.
The code has one thread that I created to handle audio record data.
The main activity has an onTouchEvent() background thread which gets called when an touch event occurs, but that code only processes input data as it occurs, and I don't touch the screen during this particular debug.
The activity also of course has the opengl onDrawFrame() thread which runs all game logic. I suppose there is a good chance this is where the problem lies.
With Opengl ES apps should game logic be run in a separate thread from the render loop? I think thread would be huge, and there would be a similar problem... graphics code executing in a thread while trying to single step through code in the debugger.
Maybe there is a way for threads to be force stopped when running in Android Studio?
[/EDIT]
I have imported into Eclipse Juno the sample of OpenCv4Android, ver. 2.4.5, called "cameracontrol". It can be found here:Camera Control OpenCv4Android Sample.
Now I want to use this project as base for mine. I want to process every frame with image-processing techniques, so, in order to improve performance, I want to split the main activity of the project in two classes: one that is merely the activity and one (a thread) that is responsible for preview.
How can I do? Are there any examples about this?
This might not be a complete answer as I'm only learning about this myself at the moment, but I'll provide as much info as I can.
You will likely have to grab the images from the camera yourself and dispatch it to threads. This is because your activity in the example gets called with a frame from the camera and has to return the frame to be displayed (immediately) as the return value. You can't get 2+ frames to process in parallel without showing a blank screen in the meantime or some other hacky stuff. You'll probably want to allocate a (fixed sized) buffer somewhere, then start processing a frame with a worker thread when you get one (this would be the dispatcher). Once your worker thread is done he notifies the dispatcher who gives the image to the view. If frames come from the camera while all worker threads are busy (i.e. there are no free slots in the buffer), the frame is dropped. Once a space in the buffer frees up again, the next frame is accepted and processed.
You can look at the code of the initialitzeCamera function of JavaCameraView and NativeCameraView to get an idea of how to do this (also google should help, as this is how apps without OpenCV have to do it as well). For me the native camera performs significantly better though (even without heavy processing it's just much smoother), but ymmv...
I can't help with actual details about the implementation since I'm not that far into it myself yet. I dope this provides some ideas though.
I am developing an Android app. I have already crossed more than 20 Activities. So I am bit concerned about it. I mean if there are more Activities in an Android app, does it affect the performance of App like Speed, Memory or any other issue?
Though it is not a standard question but still I feel its something which might help others too
Yes Suraj more activities will affect performance
An activity is the equivalent of a Frame/Window in GUI toolkits. It takes up the entire drawable area of the screen (minus the status and title bars on top). Activities are meant to display the UI and get input from the user
An Activity (calling-Activity) can spawn another Activity (sub-Activity) in 2 ways:
Fire and forget – create an event (Intent) and fire it
Async callback – create an event (Intent), fire it, and wait for it’s response in a callback method (of the calling-Activity).
So the effect of activities will depend on performance of your device, its processor and memory etc.
Even if any activity will remain in stack and not finish then it affects device performance.
Even you have to take a look at security measures.
In the Android examples, like LunarLander, and many other tutorials written on blogs across the net, game loops almost always run a separate thread to call the state updating and rendering parts of the game.
Why is this? What are the advantages and disadvantages? The only reason I can think of is just to keep the app responsive to input such as if the user presses the menu or back buttons. Other than that, the game just has to chug along in update/render cycles as fast as it can.
I'm aware this is a good reason, although one would hope that if one's game is running at a decent frame rate, the app would remain responsive enough. But, are there any other reasons?
On the other hand, I imagine it would create more headache accessing game resources, for example a game object manager or the sound system, which may live on a separate thread.
On Lunar lander and other android apps - it is important to have your surface view run on a separate thread, so that the android OS does not kill it for any long running processes.
Android keeps the main UI thread - used for the menu and home buttons among other things - avaiable to recveive user input at all times. If you app causes the main thread to slow down, the OS will kill your thread and end you game.
So running your game loop off of the Surface View thread lets you game run as fast as it can when it has focus, but it also makes it possible for android to interrupt it whenever it needs to, for instance when a call come in, or the user presses the home button.
I have a an app whose Main activity shows a GLSurfaceView. Every time that a new activity is launched, say for example Settings Activity, the OpenGl surface is destroyed, and a new one is created when the user returns to the main activity.
This is VERY slow, as I need to regenerate textures each time so that they can be bound to the new Surface. (Caching the textures is possible, but it would be my second choice, because of limited availability of memory.)
Is there a way to prevent the Surface being recreated every time?
My own analysis by looking at the code is:
There are two triggers for the Surface to be destroyed:
GLSurfaceView.onPause() is called by the activity
The view gets detached from the window
Is there a way to prevent #2 from happening when launching a new activity?
If you're targeting 3.0 or later, take a look at GLSurfaceView.setPreserveEGLContextOnPause(). Keep in mind that devices might still support only one OpenGL context at a time, so if you're switching to another activity that uses OpenGL and back to yours, you will have to reupload anyway – so I'd recommend keeping a cache and dropping it when your Activity's onLowMemory() is called.
Caching the textures is possible, by
it would be my second choice, because
of limited availability of memory
If there's a lot of textures, the only solution is to cache them AFAIK, there's no way to keep the surface and textures alive across activity restart. By the way, you can use a lot more memory in native code than in Java.
There has been a long discussion about this on android-ndk. Especially, I posted some benchmarks, which show that bitmap decoding can take up to 85% of texture loading time, texImage2D taking only the remaining 15%.
So caching decoded image data is likely to be a great performance booster, and by coupling this with memory mapped files (mmap), you may even cache a real lot of image data while staying memory-friendly.
Short answer: No
Long Answer:
You could cache/save all the textures when you get OnPause(), and restore them at OnResume(). But otherwise the android Activity lifecycle demands the view to be restored from scratch onResume()
From activity cycle
If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
One way to get around it thought is that if you are within you own Application, instead of starting a new activity, create a Overlay/Dialog over the current activity and put the SettingsView in there.