On Mon, Feb 2, 2009 at 3:54 AM, iblues <[email protected]> wrote: > > > > On Feb 2, 11:32 am, Mathias Agopian <[email protected]> wrote: >> On Sun, Feb 1, 2009 at 9:30 PM, iblues <[email protected]> wrote: >> >> > Mathias, >> >> > How does Android plan to support rendering of raw data (YUV or RGB) >> > onto the Surface at the library layers in future? For my requirement, >> > I defined my middleware class as a friend class of Surface in >> > Surface.h file. After this, I was able to access the ISurface object. >> >> Oh dear... you absolutely cannot do that. >> Android has public APIs, these are at the Java level and that's all >> you can use at the moment. >> I repeat: you CANNOT use native APIs. period. >> >> There are no way to display graphics from native code currently. > > Mathias, > But currently that is the way how the Media Player and Camera modules > are rendering the data onto the Surface right? I picked my idea of a > native implementation from those code flow only.
Yes, and those are *internal* implementation of a functionality exposed in java. > >> > Do you mean that my native library would become obselete in future? Do >> >> Yes. It will crash. >> > > Aaaah.. There goes all my work.. :( > >> > you have any recommendations for an alternate way for rendering raw >> > data? >> >> You can do this from Java, using the Bitmap.java class. >> >> Mathias >> > > In my requirement, I will be having streaming frame data being pushed > onto my native library (imagine a Video Call use case). In this case, > will it be efficient to pass this raw YUV data all the way from my > native code back to the application (activity class) using JNI, > convert the same to RGB and then to Pixel array and then finally > create a Bitmap out of this?? Wouldn't this approach eat up more > resources? > There are no very efficient ways to do these things currently. You could do the YUV conversion in your native library, which would help a little. > In the end, I believe the flow of the code goes back to the ISurface > via SurfaceFlinger right? no. btw, if your application runs on a device that support overlays (for instance), your code will also break. I'm sorry, the functionality you want is not part of the current SDK and cannot be achieved efficiently with the current public APIs. mathias > Correct me if I am wrong in any of my points. > > Regards, > iblues > > --------------------- > >> >> >> >> >> > Regards, >> > iblues >> >> > ----------------------------- >> >> > On Feb 1, 4:00 am, Mathias Agopian <[email protected]> wrote: >> >> >> ISurface is NOT a public API, nor is SurfaceHolder.getISurface(), they >> >> will change in the near future. Nothing will be made to try to >> >> maintain backward compatibility. >> >> >> mathias- Hide quoted text - >> >> - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
