I'm looking to incorporate 4 real time scatter-plots into a graph and it has been requested that they be separated (at least in pairs) to make it easier to pick out signals. Would it be less resource intensive to have multiple plotspaces on my graph, or shift a new set of axes and plots on the same plotspace? Is this still the case if I add 2-4 more scatter-plots (for 6-8 total)?
FYI, I'm currently using CorePlot 1.6 (haven't had time to make the jump to 2.0).
If all of the plots are in the same graph, use multiple plot spaces. A plot space just defines a coordinate mapping between the data and the screen so it does't use any video memory or other system resources (just a small amount of memory for the plot space object itself). Each plot and axis are CALayer objects, so those will be the primary drivers of resource usage.
Related
i use teechart pro vcl for plot charts from input data.
i read data from comport and add points to TFastlineseries with this code :
var
a : integer;
b : double;
-----------------------------
With Dbchart1.Series[0] Do
Begin
Series0.AddXY(a, b, '', clTeeColor);
end;
i have very simple 2d or sometimes 3d colorfully graphs with more than 100000 points. but after 20000 points the rendering gets very slow and in some place it will be stop.
what can i do!? is there any algorithm for improve this situation?
Turn off drawing all the points.
Series0.DrawAllPoints := false;
From Real-time charting in TeeChart VCL:
TFastLineSeries introduces several properties for fast drawing
The DrawAllPoints boolean property, default value True. Normally
chart size is limited to a fixed number of screen pixels. This means
that if, for example, you have 1.000.000 points, they will inevitably
"share" the same screen pixel coordinate (in horizontal, vertical or
both directions). Drawing an algorithm will then plot multiple points
with different real x,y coordinates at the same screen coordinate.
After multiple calls to drawing the algorithm and waste of cpu time
you'll end up with a single painted screen pixel. In this case a
reasonable thing to do is group the points with the same x screen
pixel coordinate and replace them with two points (group minimum and
maximum values). The end result will visually be the same as drawing
all the points in the group. But it will be a lot faster, especially
if there are lots of points per group. Setting DrawAllPoints to False
does precisely that : the internal algorithm processes data and draws
only non-repeated (group) points. Using this trick you can plot
millions of points in realtime with little fuss.
The PDF also mentions how to delete from a series in real time.
Series Delete method. The Delete method now includes a second
parameter which controls how many points will be deleted from a
series. This allows fast delete of multiple points in a single call,
which is much faster than deleting multiple points using a loop.
I wonder if there any downsides of using satellite mode in MKMapView?
If it performing as good as the standard map type? Maybe it devours more RAM or downloads more data?
I'm asking because this would be a much better solution in my app to use only satelite view, but I'd like to know if there are any consequences in advance.
As I check it right now, I cannot see any performance decrease comparing to standard mapView type. However, I believe that my use case is pretty basic at the moment and probably some issues I cannot detect this way.
So my questions is about known issues with performance using satelite view.
EDIT
I played(zoomed, jump all over the world etc) with both satelite and standard map and it turns out that satelite consumes less memory than standard one. How come?
Based on doing map tile (256 X 256) captures for offline use, satellite and hybrid map tiles average around 90K Bytes each in rural areas while standard map tiles average about 10K bytes each in those same areas, so there is a major impact on the volume of data downloaded and therefore on the time required. Note that there is fairly wide variance in the sizes from tile to tile depending on content, though the ratio stays pretty close.
I need to segment a set of unknown objects (books, cans, toys, boxes, etc.) standing on top of a surface (table top, floor…). I want to extract a mask (either binary or probabilistic) for each object on the scene.
I do know what the appearance of the surface is (a color model). The size, geometry, amount, appearance of the objects is arbitrary, and they could be texture-less as well). Multiple views might be available as well. No user interaction is available.
I have been struggling on picking the best kind of algorithm for this scenario (graph based, cluster based, super-pixels, etc.). This comes, naturally from a lack of experience with different methods. I'd like to know how they compare one to another.
I have some constraints:
Can’t use libraries (it’s a legal constraint, except for OpenCV). So any algorithm must be implemented by me. So I’d like to choose an algorithm that is simple enough to be implemented in a non-too-long period of time.
Performance is VERY important. There will be many other processes running at the same time, so I can’t afford to have a slow method.
It’s much preferred to have a fast and simple method with less resolution than something complex and slow that provides better results.
Any suggestion on some approach suitable for this scenario would be appreciated.
For speed, I'd quickly segment the image into surface and non-surface (stuff). So this at least gets you from 24 bits (color?) to 8 bits or even one bit, if you are brave.
From there you need to aggregate and filter the regions into blobs of appropriate size. For that, I'd try a morphological (or linear) filter that is keyed to a disk that would just fit inside the smallest object of interest. This would be an opening and a closing. Perhaps starting with smaller radii for better results.
From there, you should have an image of blobs that can be found and discriminated. Each blob or region should designate the objects of interest.
Note that if you can get to a 1-bit image, things can go VERY fast. However, efficient tools that can make use of this data form (8 pixels per character) are often not forthcoming.
I've been thinking of making a top-down 2D game with a pseudo-infinite runtime procedural generated world. I've read several articles about procedural generation and, maybe I've misread or misunderstood them, but I have yet to come across one explaining how to divide the world into chunks (like Minecraft apparently does).
Obviously, I need to generate only the part of the world that the player can currently see. If my game is tile-based, for example, I could divide the world into n*n chunks. If the player were at the border of such a chunk, I would also generate the adjacent chunk(s).
What I can't figure out is how exactly do I take a procedural world generation algorithm and only use it on one chunk at a time. For example, if I have an algorithm that generates a big structure (e.g. castle, forest, river) that would spread across many chunks, how can I adjust it to generate only one chunk, and afterwards the adjacent chunks?
I apologize if I completely missed something obvious. Thank you in advance!
Study the Midpoint displacement algorithm. Note that the points all along one side are based on the starting values of the corners. You can calculate them without knowing the rest of the grid.
I used this approach to generate terrain. I needed the edges of each 'chunk' of terrain to line up with the adjacent chunks. Using a variation of the Midpoint displacement algorithm I made it so that the height of each point along the edge of a chunk was calculated based only on values at the two corners. If I needed to add randomness, I seeded a random number generator with data from the two corners. This way, any two adjacent chunks could be generated independently and the edges were sure to match.
You can use approaches for height-maps for other things. Instead of height, the data could determine vegetation type, population density, etc. Instead of a chunks of height map where the hills and valleys match up you can have a vegetation map where the forests match up.
It certainly takes some creative programming for any kind of complex world.
I'm drawing graphs with force-directed layout, and the problem is that the created graphs are oriented randomly and unpredictably, which makes looking at them somewhat confusing. For example, suppose node A is a member of the two separate graphs G1 and G2. With force-directed layout, node A may end up on the left side of G1, but on the right side of G2.
Now I'm trying to reduce the confusion by automatically rotating the graph in a deterministic way after the graph layout algorithm has been applied to it. One could compute the minimum bounding rectangle for this, but it would be nicer if the rotation algorithm could include some of the additional information on the vertices and edges.
In this case, each vertex is a document with a timestamp and a word count, and the edges represent undirected and directed relationships between the documents. Perhaps there's a way to rotate the graph so that older documents concentrate on the left, and newer ones on the right? Same with links: The arrows should point more to the right than to the left. This sounds like a reasonable approach, but I have no idea how to calculate something like this (and Google didn't really help either).
Notes:
I think there are graph layout algorithms that take care of the rotation, but I'd prefer a solution that involves force-directed layout.
One could let the user rotate the graph by hand, but this requires saving the graph orientation, which is something I'd prefer to avoid, cause there's no room for this in the document database.
You can either use
a dynamic force-directed algorithm that preserves a user's mental map between frames (e.g. Graph Drawing in Motion, in Journal of Graph Algorithms and Applications (JGAA), 6(3), 353–-370, 2002), or
Procrustes Analysis to translate, rotate and scale frames so that the relative positions of "landmarks points" are preserved.
You may use a layout which uses a seed to generate random numbers. Try the Yifan Hu multilevel algorithm in Gephi.