Develop Reference

Draw smooth line graph with high performance

I need to draw line graph with lakes of points in canvas rendering. I used following ways to optimize the performance,
Avoided to create object in onDraw method.
Using drawLines method in canvas rather than using path.moveTo and path.lineTo, since, my thought is path is always render using CPU not GPU.
Removed line anti-alias.
Not set alpha value for line color.
Set HardwareAcceleration to true.
Using some sampling algorithms.
This is what i actually doing after read some performance tips to get good performance, If you know to make even better please suggest to me.

Instead of drawLine you can use drawRect. And use SurfaceView. (Quite honestly, I don't like SurfaceView for some limitations it has and organise back buffers myself, but most of developers prefer it).
This is what comes to my mind (without testing and thinking much).
Suppose you have a table grpData[] of float data, each in range 0f to 1f. You also have a table of colours (not colour resource Ids) grpColours.
Them your code will look smth like this:
private Paint p = new Paint();
#Override
public void onDraw(Canvas canvas) {
super.onDraw(canvas); // Draws background
int width = getWidth();
int height = getHeight();
int count = grpData.length;
float xStep = (float) width / count;
float x=0f;
for (int i=0; i<count, i++) {
float nextX = x+xStep;
p.setColor(grpColours[i]);
canvas.drawRect(x, (1f-grpData[i])*height, nextX, height, p);
x = nextX;
}
}
PS. I am not sure that hardware acceleration really helps. On the contrary it may cause problems with some cheap devices.

Android AndEngine two circles collision perfectly

Android AndEngine two circles collision perfectly. I have two circle and a collision method for them, I want when they touch each other the collision happens, currently when they near each other the collision happens.
I think that it is because of the transparent free space in the .png file of each circle.
In the picture you can see that now they collide from a distance, I want when both touch each other.
My collision method:
if (circle1.collidesWith(circle)){
Score += 1;
}

I am almost sure you are right that transparent places in png causes it. You probably creating BoxBody. In your case you should use circle body like this:
Body circleBody = PhysicsFactory.createCircleBody(pWorld, pSprite, BodyType.StaticBody, FixtureDef);
If it doesn't help there is method overload where you can provide position and size of the body. I can recommend you using DebugRender which you only have to attach to scene:
new DebugRenderer(physicsWorld, vbom)
When u use this you will see how helpful it can be:) Just remember that it may slowdown your phone when you have a lot of bodies on the scene.
PS. You didn't give us a lot of information but you should use contactListener to check colisions. There are plenty of tutorials in the internet for it
PS2. If you don't use Box2D extension - do it. This is great feature of AndEngine and it's pointless to implement that for yourself. It will be hard to detect circle shape collision of 2 objects without Box2D.

If you are not in Box2d , You must use Pixel-Perfect Collision library. Well default AndEngine Library, Does not support pixel perfect collision. To get this support, you need to import this library in eclipse and add this to your project uses library.
Here, I Demonstrate how to use this library. When you define Texture and Atlas for your sprite write as below.
private BitmapTextureAtlas lifeAtlas;
public PixelPerfectTiledTextureRegion life_Texture;
PixelPerfectTextureRegionFactory.setAssetBasePath("gfx/game/");
lifeAtlas = new BitmapTextureAtlas(textureManager, 1280, 128,
TextureOptions.BILINEAR);
life_Texture = PixelPerfectTextureRegionFactory.createTiledFromAsset(
lifeAtlas, activity, "heart_tiled.png", 0, 0, 10, 1, 0);
lifeAtlas.load();
For your custom sprite class,
public class Plane extends PixelPerfectAnimatedSprite {
public Plane(float pX, float pY,
PixelPerfectTiledTextureRegion pTiledTextureRegion,
VertexBufferObjectManager pVertexBufferObjectManager) {
super(pX, pY, pTiledTextureRegion, pVertexBufferObjectManager);
setColor(Color.GREEN);
}
}
You also need some adjustment with your AndEngine library to use it. Follow this thread to go.

Canvas.drawCircle() with large circles under hardware acceleration

In the course of developing an Android application, I'm finding a need to draw
several unfilled concentric circles centered on an arbitrary point, enough that
some of them are only partly visible on the display. However, this does not
appear to work with hardware acceleration. My test rig is a stock Samsung Galaxy
Tab 10.1 running Android 3.2.
The following code comes from a test subclass of View I wrote to isolate the
issue:
private Paint paint = new Paint();
private int count = 0;
private static final int[] COLORS = { 0xffff0000, 0xff00ff00, 0xff0000ff, 0xffff00ff };
public TestCircles(Context context) {
super(context);
paint.setStrokeWidth(1.0f);
paint.setStyle(Paint.Style.STROKE);
}
public TestCircles(Context context, AttributeSet attributes) {
super(context, attributes);
paint.setStrokeWidth(1.0f);
paint.setStyle(Paint.Style.STROKE);
}
public boolean onTouchEvent(MotionEvent e) {
if (e.getAction() == MotionEvent.ACTION_DOWN)
invalidate();
return true;
}
protected void onDraw(Canvas canvas) {
// Pick the color to use, cycling through the colors list repeatedly, so that we can
// see the different redraws.
paint.setColor(COLORS[count++]);
count %= COLORS.length;
// Set up the parameters for the circles; they will be centered at the center of the
// canvas and have a maximum radius equal to the distance between a canvas corner
// point and its center.
final float x = canvas.getWidth() / 2f;
final float y = canvas.getHeight() / 2f;
final float maxRadius = (float) Math.sqrt((x * x) + (y * y));
// Paint the rings until the rings are too large to see.
for (float radius = 20; radius < maxRadius;
radius += 20)
canvas.drawCircle(x, y, radius, paint);
}
I am running TestCircles as the only View in an Activity, laying it out to fill
the available width and height (i.e. it is nearly full-screen). I can tap on
the display (triggering redraws) only a few times before the redraws no longer
occur (i.e. the circles' color doesn't change). Actually, the onDraw() code is
still running in response to each tap -- as proven with diagnostic messages --
but nothing changes onscreen.
When onDraw() first starts to fail to redraw, the debug log includes the
following entry, once for every call to onDraw():
E/OpenGLRenderer(21867): OpenGLRenderer is out of memory!
If I turn off hardware acceleration in the manifest, these problems go away --
not surprising since clearly OpenGL is having problems -- and actually it is
a good deal faster than the few times it actually works under hardware
acceleration.
My questions are:
Am I misusing Canvas, or is this a bug, or both? Is Android allocating large
bitmaps under the hood to draw these circles? It doesn't seem like this should be
this challenging to OpenGL, but I'm new to hardware accelerated app development.
What's a good alternative way to draw large unfilled circles that have portions
extending out of the clipping region of the Canvas? Losing hardware acceleration
is not an option.
Thanks in advance...

I've since learned from others that the problem I described here is the result of a bug in Android 3.2. The workaround for now is of course to use a software layer instead of hardware acceleration. Apparently this problem is fixed in Android 4.0 (Ice Cream Sandwich).

Can't avoid GCs in simple draw loops

I'm trying to test out some different methods of drawing to a Canvas, without triggering garbage collection. Even the most basic examples cause frequent gcs. Example:
class Panel extends View {
private int mX = 0;
private Paint mPaint = new Paint();
public Panel(Context context) {
super(context);
mPaint.setColor(0xFFFF0000);
}
#Override
public void onDraw(Canvas canvas) {
canvas.drawColor(Color.BLACK);
canvas.drawRect(mX, 0, mX+40, 40, mPaint);
mX++;
postInvalidate();
}
}
I get the same result with SurfaceView (lunar lander example). GCs about every 10 seconds or so, pretty jarring in a realtime game. I'm not making any allocations in the draw loop above, so something must be allocated in the canvas etc classes (unfortunately).
I had success with an opengl test, no gcs, but I was hoping to avoid getting into opengl. I'm pretty familiar with it, but it's going to be tough drawing some effects I wanted to achieve using opengl.
Thanks

postInvalidate() may have to create an object. Use invalidate() instead, there is no reason to use postInvalidate() here.

Instead of guessing you should take a look at what is allocated.

How can I tell if a closed path contains a given point?

In Android, I have a Path object which I happen to know defines a closed path, and I need to figure out if a given point is contained within the path. What I was hoping for was something along the lines of
path.contains(int x, int y)
but that doesn't seem to exist.
The specific reason I'm looking for this is because I have a collection of shapes on screen defined as paths, and I want to figure out which one the user clicked on. If there is a better way to be approaching this such as using different UI elements rather than doing it "the hard way" myself, I'm open to suggestions.
I'm open to writing an algorithm myself if I have to, but that means different research I guess.

Here is what I did and it seems to work:
RectF rectF = new RectF();
path.computeBounds(rectF, true);
region = new Region();
region.setPath(path, new Region((int) rectF.left, (int) rectF.top, (int) rectF.right, (int) rectF.bottom));
Now you can use the region.contains(x,y) method.
Point point = new Point();
mapView.getProjection().toPixels(geoPoint, point);
if (region.contains(point.x, point.y)) {
// Within the path.
}
** Update on 6/7/2010 **
The region.setPath method will cause my app to crash (no warning message) if the rectF is too large. Here is my solution:
// Get the screen rect. If this intersects with the path's rect
// then lets display this zone. The rectF will become the
// intersection of the two rects. This will decrease the size therefor no more crashes.
Rect drawableRect = new Rect();
mapView.getDrawingRect(drawableRect);
if (rectF.intersects(drawableRect.left, drawableRect.top, drawableRect.right, drawableRect.bottom)) {
// ... Display Zone.
}

The android.graphics.Path class doesn't have such a method. The Canvas class does have a clipping region that can be set to a path, there is no way to test it against a point. You might try Canvas.quickReject, testing against a single point rectangle (or a 1x1 Rect). I don't know if that would really check against the path or just the enclosing rectangle, though.
The Region class clearly only keeps track of the containing rectangle.
You might consider drawing each of your regions into an 8-bit alpha layer Bitmap with each Path filled in it's own 'color' value (make sure anti-aliasing is turned off in your Paint). This creates kind of a mask for each path filled with an index to the path that filled it. Then you could just use the pixel value as an index into your list of paths.
Bitmap lookup = Bitmap.createBitmap(width, height, Bitmap.Config.ALPHA_8);
//do this so that regions outside any path have a default
//path index of 255
lookup.eraseColor(0xFF000000);
Canvas canvas = new Canvas(lookup);
Paint paint = new Paint();
//these are defaults, you only need them if reusing a Paint
paint.setAntiAlias(false);
paint.setStyle(Paint.Style.FILL);
for(int i=0;i<paths.size();i++)
{
paint.setColor(i<<24); // use only alpha value for color 0xXX000000
canvas.drawPath(paths.get(i), paint);
}
Then look up points,
int pathIndex = lookup.getPixel(x, y);
pathIndex >>>= 24;
Be sure to check for 255 (no path) if there are unfilled points.

WebKit's SkiaUtils has a C++ work-around for Randy Findley's bug:
bool SkPathContainsPoint(SkPath* originalPath, const FloatPoint& point, SkPath::FillType ft)
{
SkRegion rgn;
SkRegion clip;
SkPath::FillType originalFillType = originalPath->getFillType();
const SkPath* path = originalPath;
SkPath scaledPath;
int scale = 1;
SkRect bounds = originalPath->getBounds();
// We can immediately return false if the point is outside the bounding rect
if (!bounds.contains(SkFloatToScalar(point.x()), SkFloatToScalar(point.y())))
return false;
originalPath->setFillType(ft);
// Skia has trouble with coordinates close to the max signed 16-bit values
// If we have those, we need to scale.
//
// TODO: remove this code once Skia is patched to work properly with large
// values
const SkScalar kMaxCoordinate = SkIntToScalar(1<<15);
SkScalar biggestCoord = std::max(std::max(std::max(bounds.fRight, bounds.fBottom), -bounds.fLeft), -bounds.fTop);
if (biggestCoord > kMaxCoordinate) {
scale = SkScalarCeil(SkScalarDiv(biggestCoord, kMaxCoordinate));
SkMatrix m;
m.setScale(SkScalarInvert(SkIntToScalar(scale)), SkScalarInvert(SkIntToScalar(scale)));
originalPath->transform(m, &scaledPath);
path = &scaledPath;
}
int x = static_cast<int>(floorf(point.x() / scale));
int y = static_cast<int>(floorf(point.y() / scale));
clip.setRect(x, y, x + 1, y + 1);
bool contains = rgn.setPath(*path, clip);
originalPath->setFillType(originalFillType);
return contains;
}

I know I'm a bit late to the party, but I would solve this problem by thinking about it like determining whether or not a point is in a polygon.
http://en.wikipedia.org/wiki/Point_in_polygon
The math computes more slowly when you're looking at Bezier splines instead of line segments, but drawing a ray from the point still works.

For completeness, I want to make a couple notes here:
As of API 19, there is an intersection operation for Paths. You could create a very small square path around your test point, intersect it with the Path, and see if the result is empty or not.
You can convert Paths to Regions and do a contains() operation. However Regions work in integer coordinates, and I think they use transformed (pixel) coordinates, so you'll have to work with that. I also suspect that the conversion process is computationally intensive.
The edge-crossing algorithm that Hans posted is good and quick, but you have to be very careful for certain corner cases such as when the ray passes directly through a vertex, or intersects a horizontal edge, or when round-off error is a problem, which it always is.
The winding number method is pretty much fool proof, but involves a lot of trig and is computationally expensive.
This paper by Dan Sunday gives a hybrid algorithm that's as accurate as the winding number but as computationally simple as the ray-casting algorithm. It blew me away how elegant it was.
See https://stackoverflow.com/a/33974251/338479 for my code which will do point-in-path calculation for a path consisting of line segments, arcs, and circles.