skia

[Pawel Veselov]

Hi,

are there any plans to expose skia library to the NDK?
Considering that platform uses this library for graphical
manipulation, exposing it would allow developers to tap into native
handlers of graphic objects, quite improving the performance.

Thanks,
Pawel.

[Jack Palevich]

There are no plans to expose the native Skia APIs to the NDK.

Why not? Well, we don't want to have to support its native API going forward. We want the freedom to change the native API as necessary.

If you would like to use Skia from your NDK application there are two reasonable approaches:

A) You can use Skia through the Android Java APIs. Depending upon the operation this might not be that much slower than calling the Skia native API directly.

B) Skia is open sourced at http://code.google.com/p/skia/ , so you are welcome to compile and include a copy of the open source version of Skia in your own application.

[Pawel Veselov]

Understood.

The performance problems related to that are mostly around dealing
with Java arrays, which is the only way to transfer [image] data
between native and java code.

If I try having my version of the library to handle native handlers
returned from Java objects, that would probably lead to segfaults all
around :)

Well, I'm off to explore how data transfer would work if I use direct buffers :)

Thank you.

[shagrath]

I suggest to use the ByteBuffer.allocateDirect java method /
GetDirectBufferAddress jni method to exchange big image/array data.
That's what i'm doing and it's working great (and you don't need to
take care of the buffer release if I'm correct, Java gc will do it for
you)

On Sep 17, 7:54 pm, Pawel Veselov <pawel.vese...@gmail.com> wrote:
> Understood.
>
> The performance problems related to that are mostly around dealing
> with Java arrays, which is the only way to transfer [image] data
> between native and java code.
>
> If I try having my version of the library to handle native handlers
> returned from Java objects, that would probably lead to segfaults all
> around :)
>
> Well, I'm off to explore how data transfer would work if I use direct buffers :)
>
> Thank you.
>
>
>
> On Thu, Sep 17, 2009 at 10:21 AM, Jack Palevich <jack...@google.com> wrote:
> > There are no plans to expose the native Skia APIs to the NDK.
> > Why not? Well, we don't want to have to support its native API going
> > forward. We want the freedom to change the native API as necessary.
> > If you would like to use Skia from your NDK application there are two
> > reasonable approaches:
>
> > A) You can use Skia through the Android Java APIs. Depending upon the
> > operation this might not be that much slower than calling the Skia native
> > API directly.

> > B) Skia is open sourced at http://code.google.com/p/skia/, so you are

> > welcome to compile and include a copy of the open source version of Skia in
> > your own application.
>

> > On Thu, Sep 17, 2009 at 9:56 AM, Pawel Veselov <pawel.vese...@gmail.com>

[jc]

Is the skia library using hardware acceleration
for its jpeg encoding? Would there be a way to tap into
the hardware acceleration for encoding to jpeg from the ndk?

[Jack Palevich]

This isn't an appropriate topic for the NDK mailing list, because it is not about the NDK. It would be better to ask this on a more appropriate newsgroup like android-developers.

However, to save you time, I think I can answer it anyway:

No, and no. Sorry!

Skia just calls libjpeg, and libjpeg is just the standard C implementation.

Android devices typically come with camera device drivers that typically encode the camera jpeg images in hardware, but I don't think there is an API for fast encoding arbitrary user-created images. It's a good idea, you might want to file a feature request.

http://code.google.com/p/android/issues/list