I've written a speedlimit app that loads data from a set of tiled xml files representing 0.05 sided degree maps.
At the moment, the app checks if I've moved into a new square (using OnLocationChanged) and if so loads in the data for it and the surrounding other 8 tiles.(has a bit of a sanity check and only loads data for new tiles so tends to just load in another 3 tiles worth of data)
Anyway, it currently does this on the UI thread and so there is a noticeable pause when moving into new square and I'd like to shift it to background using Asynctask (It also loads in bitmap maps for display purposes and I've already moved that code into an Asynctask so I know how to do that bit)
My problem is to do with checking the arrays (actually using ArrayLists) used for the speed limits while the Asynctask is possibly adding (and in future version - subtracting) to them in the background.
I was wondering if there was a "professional" :) way of dealing with this sort of situation.
A synchronized access should be dealing with all problems of concurrency accessing the ArrayList. Just use
synchronized(myArrayList) {
// update/read/modifiy
}
Both in your AsyncTask and your UI.
Good resource is the stackoverflow search
Related
I am writing a 3D viewer which loads some 3D file and displays it simply on a GLSurfaceView.
I originally implemented the viewer in opengles10, however since this is a fixed function api, I was not able to use shaders, and since have moved to opengles20.
A few questions here:
When I load similar models with opengles10 on my HTC desire, things are quick, touch events are as expected mathematically and the model rotates/translates/zooms easily.
However when I use opengles20, my touch events cause hell. I know this because on a onFling event, I rotate my model with a damping factor. This is smooth in all cases.
So :
1) Why in opengles20 do I need to worry about vsyncs and double buffering and a choreographer ??
2) How do i implement double buffering or swap buffers with opengl if the buffers are not available to me ??
3) Is this the only reason for the performance difference ??
4) Finally, what can I do to equate these two ?? An upgrade from opengles10 to opengles20 isn't really a great update if my UI is laggy
Following up on my own question here :
I've decided to use RENDERMODE_CONTINUOUSLY for my rendermode; this allows opengl to swap buffers anytime it can and re-draw.
I also moved my logic for applying rotations/translation to matrices outside the drawing loop.
And lastly, to get all this to play nicely, introduced a mutex to synchronize on, that way updating rotations/translation is thread safe against the opengles thread
I have seen a few programs and games that store their data in an indexed file, and they load their data from that file which they usually call cache.
I want to be able to load my data in this way:
final int SPRITES_INDEX = 3;
List<Sprite> sprites = (List<Sprite>) cache.loadIndex(SPRITES_INDEX);
Does any know how it's done and why its done this way? or is there a name for this method of storing data?
You should look up "resources" in "jar" files. That's what is commonly used for this job in the java world. Normally a jar file is just a zip file, which is sequential, but many years ago they added the ability to have indexed jar files, which provide random access to their contents.
You can begin here: http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/jar.html
(Look for the "i" option which adds an index to the jar file.)
At least for images/rendering, this is called Texture Packing, and is done because OpenGL "binds" images before rendering them, and this binding can be expensive, processing-wise.
Packaging the textures inside a larger image allows the game/app to bind only once, and then, based on an index of predefined pixel coordinates, render only parts of the larger image, as if they were separate smaller images.
I suggest taking a look at LibGDX's TexturePacker.
Extract:
In OpenGL, a texture is bound, some drawing is done, another texture
is bound, more drawing is done, etc. Binding the texture is relatively
expensive, so it is ideal to store many smaller images on a larger
image, bind the larger texture once, then draw portions of it many
times. libgdx has a TexturePacker class which is a command line
application that packs many smaller images on to larger images. It
stores the locations of the smaller images so they are easily
referenced by name in your application using the TextureAtlas class.
TexturePacker uses multiple packing algorithms but the most important
is based on the maximal rectangles algorithm. It also uses brute
force, packing with numerous heuristics at various sizes and then
choosing the most efficient result.
Note that this is a type of, and similar but not identical to, the general concept of Caching.
In computer programming, caching consists of dedicating a section of memory to storing recently or frequently used data, to avoid having to recreate/reprocess that data every time it is needed/accessed.
As such, it's similar, but not the same to the concept of texture-packing, which instead is done not to recreate/reprocess the images themselves, but rather to avoid an expensive complication/process further down the line.
Considering the gaming context of the question, it's also important to note that another concept, this time much closer to caching, exists. It's called Pooling, and consists of creating a cache (in this case called Pool) of pre-created/pre-processed instances of objects that can be expected to be needed in varied quantity over time, for examples the units in an RTS game, to avoid having to create them when they are needed (in turn to avoid sudden "weight" in processing, which leads to sudden drops in FPS, or "stutters", in the context of a game).
Which is best for Android?
I have 30 3D models but there is only ever one drawn on the screen at any time.
Do I:
create the model and destroy the previous model every time the displayed one changes.
or
create all 30, store them and just reference them when I want to draw them.
Note that when one model is removed another model appears and the transition must be smooth.
In what context would one be better than the other?
Have you tried loading all of them at once? Start with that, and if it doesn't work, then look at memory management. You should be able to keep at least three or four models in memory on an older device. If you do have issues with ram, try to predict which models are going to be used next, and pre-load them in.
Keeping them all loaded is normally preferable, because it means your app will appear fluid and responsive.
I am rendering rather heavy object consisting of about 500k triangles. I use opengl display list and in render method just call glCallList. I thought that once graphic primitives is compiled into display list cpu work is done and it just tells gpu to draw. But now one cpu core is loaded up to 100%.
Could you give me some clues why does it happen?
UPDATE: I have checked how long does it take to run glCallList, it's fast, it takes about 30 milliseconds to run it
Most likely you are hitting the limits on the list length, which are at 64k verteces per list. Try to split your 500k triangles (1500k verteces?) into smaller chunks and see what you get.
btw which graphical chips are you using? If the verteces are processed on CPU, that also might be a problem
It's a bit of a myth that display lists magically offload everything to the GPU. If that was really the case, texture objects and vertex buffers wouldn't have needed to be added to OpenGL. All the display list really is, is a convenient way of replaying a sequence of OpenGL calls and hopefully saving some of the function call/data conversion overhead (see here). None of the PC HW implementations I've used seem to have done anything more than that so far as I can tell; maybe it was different back in the days of SGI workstations, but these days buffer objects are the way to go. (And modern OpenGL books like OpenGL Distilled give glBegin/glEnd etc the briefest of mentions only before getting stuck into the new stuff).
The one place I have seen display lists make a huge difference is the GLX/X11 case where your app is running remotely to your display (X11 "server"); in that case using a display list really does push all the display-list state to the display side just once, whereas a non-display-list immediate-mode app needs to send a bunch of stuff again each frame using lots more bandwidth.
However, display lists aside, you should be aware of some issues around vsync and busy waiting (or the illusion of it)... see this question/answer.
In an OpenGL ES 1.x Android application, I generate a circle (from triangles) and then translate it about one hundred times to form a level. Everything works except when a certain event occurs that causes about 15 objects to be immediately added to the arraylist that stores the circles' coordinates. When this event happens 2+ times quickly, all the circles in the list disappear for about 1/5th of a second. Besides this, the circles animate smoothly.
The program runs well as a java SE app using the same synchronization techniques, and I have tried a half a dozen or so other synch techniques to no avail, so I feel the problem is the openGL implementation. Any suggestions?
Do you really have to store the vertex data in client memory? If you don't modify it, I suggest you use a VBO instead. Just upload it into graphics memory once, then draw from there. It will be much faster (not requiring you to send all the vertex data for each draw), and I'm pretty sure you won't run into the problem you described.
Transformations can be done as much as you like, then you only have to give the draw command for each instance of your circle.
So the list is being modified under your nose? It sounds like you need to do any modification to this list on the OpenGL thread. Try Activity.postOnUiThread(Runnable), where Runnable implements your own code. Possibly.