Android View vs SurfaceView vs GLSurfaceView for 2D drawing app with Zoomable User Interface

Question

I plan to write a 2D drawing app with a zoomable user interface. With the app the user should be able to transform (translate and scale) drawn paths (and of course the UI). I assume that there will be up to 500 paths at the same time. Now, I am wondering which view to start off with (View, SurfaceView or GLSurfaceView ) in order to provide acceptable performance. I read a couple of posts [1-6] including the once on android developer guide and am still not 100% sure which view to use.

According to the presentation at Google I/O 2009 (http://youtu.be/U4Bk5rmIpic?t=45m10s) and own experiences canvas (View and SurfaceView) doesn't seem to be performing fast enough when handling more than 100 paths.

Does anyone see a possibility in implementing the app using canvas or is OpenGL the way to go?

[1] Android: Deciding between SurfaceView and OpenGL (GLSurfaceView)

[2] SurfaceView or GLSurfaceview?

[3] Difference between SurfaceView and View?

[4] http://pierrchen.blogspot.jp/2014/03/anroid-graphics-surfaceview-all-you.html

[5] Difference between SurfaceView and ImageView

[6] Difference between SurfaceView and GLSurfaceView in Android

Biotite

Answer 1

Because of your performance concerns, you will need to use hardware rendering. Displays keep getting denser, so touching every pixel in software is getting slower.

If you want to draw with a Canvas, you must render to a custom View, with hardware acceleration enabled. Canvas rendering on a Surface is always done with software.

SurfaceView and GLSurfaceView are nearly the same thing; GLSurfaceView just has some helper functions that take care of some of the housekeeping for you. You can use GLES to render on SurfaceView and TextureView. There are multiple examples of this in Grafika.

If you want to know what's going on under the hood, see the System-Level Graphics Architecture doc.

You may want to consider the use of an open-source 2D game engine. That'll handle the EGL setup, should provide code for GLES font rendering, and so on.

Popper

Hi! Thanks for this informative answer! I was writing the same question as OP's and just found your answer. You must be a very experienced person on Android, I guess. What I'm writing is a simple painting feature. Because the function is just a little part of my app, I didn't choose GLSurfaceView but wrote my own custom View. I used to make windows games using DirectX, so if I was creating a game, then I would definitely use GLSurfaceView. But as I said above, painting isn't the main thing this time and works fine with View so far! – Ecliptic

Because I tested and improved this for a week, the function is stable and optimized as much as possible. So I think it's fine to finish developing it now, but I still wonder if GLSurfaceView will help reduce my latency a little bit. The latency I'm talking about isn't caused by onDraw() of View actually. The main problem is calculation logic for a very long bezier curve stroke, but I can't optimize the algorithm any more for now. As for my custom View, it does double buffering, calls invalidate() only when the image is modified, and also limits FPS -invalidate() is called 60 times per sec max. – Ecliptic

I heard hardware acceleration is supported by default from version 4.0 and that means now View also uses OpenGL. So I'm not sure it's worth trying to change my code to use GLSurfaceView and it will make feel better. What do you think? One more question. You said "If you want to draw with a Canvas, you must render to a custom View", then you mean I can't use Canvas with SurfaceView? I never tried SurfaceView things but AFAIK GLSurfaceView also needs canvas, so really confused. – Ecliptic

(1) If you want to ask a question, you should post it as a question; otherwise hardly anyone but me will see it, and you'll miss out on other opinions. (2) Use systrace to figure out where your time is being spent before you make changes. Wrap your rendering code with Trace sections (see e.g. bigflake.com/systrace). (3) "Must" in my answer is for performance reasons -- Canvas rendering to a Surface is not hardware-accelerated. (4) latency != throughput. (5) Call invalidate() all you like, View UI uses Choreographer to match the display refresh rate. – Popper

Firstly, I removed my question because I'm trying not to post duplicated questions. And the big reason I wrote here was I wanted to ask you specifically :) Your answer is really helpful as I expected, thanks a million! Have a good one!! – Ecliptic

Sorry but one final question. "Canvas rendering to a Surface is not hardware accelerated". What about GLSurfaceView then? Hardware acceleration is supported for Canvas and GLSurfaceView uses OpenGL, so using Canvas with GLSurfaceView can lead to better performance unlike normal SurfaceView? – Ecliptic

Canvas rendering onto a Surface (SurfaceView, GLSurfaceView, TextureView, MediaCodec surface input, ...) is not currently hardware-accelerated. GLSurfaceView is just a wrapper around SurfaceView that provides some GLES helper classes -- you can use GLES to render onto any Surface (as demonstrated by Grafika). – Popper

Ah.. I asked a new question related to Android here in stackoverflow, but deleted right after one guy told me I shouldn't post such a question which doesn't have any code in it. Do you know any other huge forums like stackoverflow for android developers? I tried android-developers.googlegroups.com but still no answer at all and I prefer forum to mailing list. Moreover, they're saying "If you're just starting with Android application development and have a beginner-level question, consider asking it on Stack Overflow"!! I really want to get help from experienced people like you, but where? – Ecliptic

BTW, my question was this, if you're interested. drive.google.com/file/d/0B6DSYz-ZL0d9TUhVSXRIN2xCSzA/… – Ecliptic

stackoverflow isn't great for open-ended "how should I do X" sorts of questions (see stackoverflow.com/help/dont-ask). I'm not sure where else to go other than the Google Groups lists. – Popper