I think we'll be able to give you something that will meet your needs. It's always a balancing act between taking the time to get the API just right and getting a product to market.
Keep making suggestions, we are listening. On Feb 11, 4:08 am, blindfold <seeingwithso...@gmail.com> wrote: > Thank you David, I feel relieved to hear that. :-) > > > Rather than trying to do all your image processing in Java, wouldn't you > > prefer to have built-in native signal processing kernels that are optimized > > for the platform? > > Yes, of course. One can parameterize and wrap under an API a number of > useful low-level image (and audio) operations, such as various > filtering operations, edge detection, corner detection, segmentation, > convolution and so on. That is certainly very nice to have, but not > enough. I would want to implement my own pixel-level (and audio-byte- > level) processing algorithms that do not fit within the pre-canned > categories, while benefiting from the platform and CPU independence of > Android (no JNI if I can avoid it). It would be purely computational > code with loops and conditional branches, operating on arrays, array > elements and scalars. At that level, C code (minus any pointering) and > Java code actually looks almost the same. No real need for any fancy > data structures etc at *that* level that then covers the "expensive" > parts of the processing, so I feel that a simple, light-weight, > targeted JIT compiler could come a long way to meeting all these > needs: I really would not mind if it would only compile a > (computational) subset of Java, and it may leave code optimizations to > the developer by compiling rather straightforwardly. (Cannot help > being reminded of FORTRAN-77 on old IBM mainframes getting compiled > almost 1-to-1 to easy-to-read machine code.) So perhaps rather than a > built-in native signal processing *kernel* I am here thinking of a > built-in native signal processing (JIT) *compiler*. ;-) > > Regards > > On Feb 11, 11:03 am, Dave Sparks <davidspa...@android.com> wrote: > > > I'm talking about deprecating the raw picture callback that has never > > worked. It won't affect any existing applications. As for the camera > > API in SDK 1.0: It was never intended for signal processing. It was > > intended only for taking snapshots. It just happens that creative > > people like yourself have found other uses for it. > > > I certainly don't want to break your application. I do want to give > > you a better API in the future. Rather than trying to do all your > > image processing in Java, wouldn't you prefer to have built-in native > > signal processing kernels that are optimized for the platform? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
