NDK 2D graphics

[rt_...@yahoo.com]

I have an existing large application in C code that I'm moving to
Android NDK. This app draws to a graphics context using primitive
drawing commands (draw_point, draw_line, draw_rect, ect). I am
concerned that using the Android Java primitave drawing commands will
cause a huge number of calls to go through the JNI layer. For
instance drawing a sin wave using draw_point commands.

Is there a 2D graphics package that can be used entirely native ?
Scenario would be to get a graphics context from android java. Then
have NDK code write directly to the gc buffer via 2D graphics lib.
What native 2D graphics lib would be suggested / appropriate ?

Then after NDK code via graphics lib draws to the gc buffer, this is
passed to java/android surface flinger to render to the screen.

Any advise or recommendations would be appreciated.
Regards,
Julie D

[mingw android]

OpenGL ES 2 would be an excellent choice.

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>

[Pepijn Van Eeckhoudt]

It's not trivial to use GL for 2D graphics though. The android Java 2d lib is a wrapper over skia. It's not part of the NDK, but if you compile your own build of it you might be able to use that to render 2d graphics in native code.

Pepijn 

[mingw android]

Maybe not trivial but not that bad either. It's certainly worth considering further.

On 26 Aug 2010 20:48, "Pepijn Van Eeckhoudt" <pep...@vaneeckhoudt.net> wrote:

It's not trivial to use GL for 2D graphics though. The android Java 2d lib is a wrapper over skia. It's not part of the NDK, but if you compile your own build of it you might be able to use that to render 2d graphics in native code.

Pepijn 

On 26 Aug 2010, at 20:10, mingw android <mingw....@gmail.com> wrote:

> OpenGL ES 2 would be an excellent choice.
>

> > I have an existing large application in C code tha...

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

...

[Dianne Hackborn]

You absolutely should not be using the private Skia APIs.  Your app *will* break on different devices and platform versions.

To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Tim Mensch]

On 8/26/2010 3:37 PM, Dianne Hackborn wrote:

You absolutely should not be using the private Skia APIs.  Your app *will* break on different devices and platform versions.

That's not what he is recommending. See his original statement again:

On 26 Aug 2010 20:48, "Pepijn Van Eeckhoudt" <pep...@vaneeckhoudt.net> wrote:

It's not trivial to use GL for 2D graphics though. The android Java 2d lib is a wrapper over skia. It's not part of the NDK, but if you compile your own build of it you might be able to use that to render 2d graphics in native code.

"...if you compile your own build of it..."

He's suggesting that they grab the Skia source and compile it into their app. That, at least, should be 100% supported. Correct me if I'm wrong.

Tim

[Angus Lees]

On Fri, Aug 27, 2010 at 07:37, Dianne Hackborn <hac...@android.com> wrote:
> You absolutely should not be using the private Skia APIs.  Your app *will*
> break on different devices and platform versions.

Yes, definitely don't use the internal Android skia, it changes ABI frequently.
You can get a "standalone" version of skia from
http://code.google.com/p/skia/ and use that just like you would any
other drawing library (and link it in to your app statically). When
using skia (or any other drawing library) in this way though it
obviously has to be generic code and you can't really use any hardware
optimisations.
The only way you are going to get hardware accelerated blits,
stretches, etc is via OpenGLES - the downside for 2D work is that
frequent texture uploads/downloads can be slow enough to outweigh the
hardware accelerated portions of your code, so if you go this way you
want to try to do as much as possible inside GL.

- Gus

[Dianne Hackborn]

Ah yes, linking your own build into your app is okay.

However, there isn't currently an NDK API to draw to a surface, so there will still be some problems...  There is the new AndroidBitmap API in Froyo that can help.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Robert Green]

GL is not good at doing simple client-side bitmap manipulation (and
can't on various chips due to lack of framebuffer extension support)
so I would recommend a library maybe like cairo or something.
Personally I'd just write the few routines myself using a 90s game
programming book (Zen of graphics?), but to each their own.

If all you need to do is draw circles, ellipses, boxes and have
various types of stroke and fill, you can write all of that yourself
with just a couple of days of work (about the same amount of time it
can take to get a 3rd party lib working correctly) :)

> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/android-ndk?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Danny Backx]

I'm working on porting RoadMap to Android. Calling Java from the C
language application to do *everything* is a pain to code, but it does
work. At times I had to add buffering to avoid buffer overflows.

Also the Android API appears limited at times. Many X based apis that
I've used allow you to pass some random data to an event handler. This
often comes in very handy. Not having this on Android implies caching
all kinds of data about structure dynamically built from the
application.

But the bottom line is that it does work, and it works more than
quickly
enough for my purpose.

Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

[Dsemi]

Maybe AGG can do what you are looking for:
http://www.antigrain.com

On Aug 26, 10:15 am, "rt_...@yahoo.com" <rt_...@yahoo.com> wrote:
> I have an existing large application in C code that I'm moving to
> Android NDK.  This app draws to a graphics context using primitive
> drawing commands (draw_point, draw_line, draw_rect, ect).  I am
> concerned that using the Android Java primitave drawing commands will
> cause a huge number of calls to go through the JNI layer.  For
> instance drawing a sin wave using draw_point commands.
>

> Is there a2Dgraphics package that can be used entirely native ?

> Scenario would be to get a graphics context from android java.  Then
> have NDK code write directly to the gc buffer via2Dgraphics lib.

> What native2Dgraphics lib would be suggested / appropriate ?