20

Background

I'm writing a graphing library for an android application (yes yes, I know there are plenty out there but none that offer the customizability we need).

I want the graphs to zoomable and pan-able.

Problem

I want the experience to be smooth, leave a small CPU footprint.

Solutions

View.onDraw():

Benefits

  • Some what easy to implement

Drawbacks

  • Bad performance? (unless it uses OpenGL, does it?)

Bitmap:

Benefits

  • Really easy to implement
  • Great performance

Drawbacks

  • Have to use scaling which is ugly

OpenGL:

Benefits

  • Probably good performance depending on my implementation

Drawbacks

  • More work to implement

Final words

OpenGL would probably be the professional solution and would definitely offer more flexibility but it would require more work (how much is unclear).

One thing that is definitely easier in OpenGL is panning/zooming since I can just manipulate the matrix to get it right, the rest should be harder though I think.

I'm not afraid to get my hands dirty but I want to know I'm heading in the right direction before I start digging.

Have I missed any solutions? Are all my solutions sane?


Additional notes:

I can add that when a graph changes I want to animated the changes, this will perhaps be the most demanding task of all.

1
  • +1 for really a good quality of question and representation of your question. Commented Jul 30, 2011 at 7:53

1 Answer 1

19

The problem with using Views is that you inherit from the overhead of the UI toolkit itself. While the toolkit is pretty well optimized, what it does it not necessarily what you want. The biggest drawback when you want to control your drawing is the invalidate/draw loop.

You can work around this "issue" by using a SurfaceView. A SurfaceView lets you render onto a window using your own rendering thread, thus bypassing the UI toolkit's overhead. And you can still use the Canvas 2D rendering API.

Canvas is however using a software rendering pipeline. Your performance will mostly depend on the speed of the CPU and the bandwidth available. In practice, it's rarely as fast as OpenGL. Android 3.0 offer a new hardware pipeline for Canvas but only when rendering through Views. You cannot at this time use the hardware pipeline to render directly onto a SurfaceView.

I would recommend you give SurfaceView a try first. If you write your code correctly (don't draw more than you need it, redraw only what has changed, etc.) you should be able to achieve the performance you seek. If that doesn't work, go with OpenGL.

4
  • Thanks for a good answer. I want to do animations as well (updated my question), is surface view still a good choice?
    – Nicklas A.
    Commented Jul 30, 2011 at 7:49
  • That's kinda what it's for :)
    – Romain Guy
    Commented Jul 30, 2011 at 10:22
  • Ok, is it much work converting between OpenGL and SurfaceView?
    – Nicklas A.
    Commented Jul 30, 2011 at 17:42
  • 3
    It really depends on what you are doing with Canvas and how well you know OpenGL. It can range from easy (drawing bitmaps) to complicated (arbitrary antialiased paths.)
    – Romain Guy
    Commented Jul 31, 2011 at 4:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.