[android-developers] ANN: Itoa project lets you rebuild iOS applications for Android
~~~ Well, that's the ultimate goal. Let's achieve it together -- contributors wanted! ~~~ Itoa is a cluster of open-source projects that implement compiler, build scripts and various libraries to allow building Android's apk from Objective-C source files. Two main features of Itoa are: 1. Itoa uses Android UI and graphics classes to implement iOS counterparts, so ported applications look and feel native. For example, UIButton wraps android.widged.Button and CGContext wraps android.graphics.Canvas. 2. Itoa uses Apple's open-source code (GCC patches for Objective-C 2.0, objc4 runtime and CoreFoundation library) for maximum compatibility with iOS. Here is a short overview of Itoa projects (hosted on Github) and their licenses: * itoa-main :: ItoaCore, UIKit, CoreGraphics and QuartzCore libraries (GPL). * itoa-foundation :: Foundation implementation based on Cocotron (MIT). * itoa-cleancf :: Refactored Apple's CoreFoundation; supports bridging (APSL, Apache). * itoa-objc :: Apple's objc4 runtime ported to Android (APSL, Apache). * itoa-jnipp :: General purpose C++ JNI wrappers (Apache). * itoa-macemu :: Emulation of malloc_zone_t functions and OSAtomics (Apache). * itoa-dropins :: Various utilities (notably, a C++ wrappers for pthread) used in projects (Apache). * itoa-toolchain :: GCC 4.2.1 with Objective-C 2.0 patches (GPL). * itoa-ndk :: Scripts to build, install and run Android applications from Objective-C source files (Apache). Currently Itoa is capable of building Android applications from simple iOS programs like this one: https://gist.github.com/1634076 Read more in the blog: http://itoaproject.blogspot.com Quick links: * Installation: https://github.com/DmitrySkiba/itoa/wiki/Installing-Itoa-NDK * First App: https://github.com/DmitrySkiba/itoa/wiki/First-Itoa-App -- 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
[android-developers] Re: Touch handling sleep not helping enough on 1.5/1.6
I can suggest something weird - to boost priority for the time of rendering. See how I did that in ToF: http://code.google.com/p/tapsoffire/source/browse/trunk/src/org/tof/util/GameFPSTimer.java (onBeforeRender/onAfterRender) Dmitry On 31 дек, 05:39, Robert Green rbgrn@gmail.com wrote: I hate to bump it just to bump it but I'm really in need of some good suggestions here. Thanks to anyone who can offer anything new to try. On Dec 29, 3:13 pm, Robert Green rbgrn@gmail.com wrote: Hey guys, I'm really in a bind here. I've got this new game engine that's almost done but the input system is killing me. I have a virtual analog stick on the screen and it works great, especially on Android 2.0 (Droid) but on any 1.5/1.6 device, the touching is causing my game to crawl. I know all of the standard stuff - I pipe my input events into a queue for my main game thread and then sleep for 16ms which should ensure that no more than 60 motion events are dispatched per second. That works fine but even so, just touching the screen, even with my event handling code commented out (except for the sleep, of course), drops my game from 30FPS to 20FPS. It's really bad. I bound some keyboard keys to the movement to replace the touch controls for testing and the game maintained a great framerate. That won't work because most phones now only have touchscreens so I really need to figure this one out. Wait for Android 2.0 is not a great answer, either. So far I've tried; Activity.onTouchEvent with a 16, 20, 32, 50ms sleep before returning Activity.dispatchTouchEvent with a 16,20,32 and 50ms sleep Commented out all code except the sleep to test - problem is still there, so it's not my hander. What else can I do? -- 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
[android-developers] Re: open GL ES Games on Android
Wow, nice and informative reply, thank you! Couple of points from my side: (1) use glDrawTexfOES for sprite renderings, it is super fast (2) as of 1.6 you can use OpenGL in NDK, so you can do all rendering in native code (3) Armadillo Roll is completely implemented in native code, with a tiny wrapper of Java ontop Dmitry On Dec 4, 12:39 pm, Robert Green rbgrn@gmail.com wrote: GLSurfaceView should, in theory, give you an ideal gl configuration for that device... However in practical use, there are sometimes bugs on certain devices and firmwares that don't produce the correct configuration parameters and thus you'll get bad performance. The Droid is a little different than most Android phones because it has a PowerVR SGX530 chip which is quite fast and likes a 24 bit depth buffer, as opposed to the HTC Qualcomm phones that aren't quite so fast and like a 16 bit depth buffer. Someone should correct me if I'm wrong but if you use a GLSurfaceView, you will probably get the ideal depth buffer size which will result in the best performance. Here's another performance consideration for the Droid: It has a high- res screen. It may be faster to run the game in a compatibility mode which ends up being 320x589 or as opposed to 480x854. As far as GL ES goes, you just need to get used to the arrays and reduced feature set. VBOs tend to run pretty quick on most phones. I've found that nearly all phones really hate lots of texture switching. I've got a multitextured (lightmapped) world working for my new game that's running 30-60FPS with only fog but no GL lights on my G1. A small lightmap and everything linear makes that work. I also wrote a Quake 2 level (BSP) renderer recently but scrapped it because it was taking too long to get the optimizations in to render quickly. GLES doesn't like to render 1500 faces all as separate DrawArrays calls. It's too much. I was about to work on batching them up and atlasing the textures, which would have worked fine but it was turning into a big pain so I switched over to a simpler system and will be just using an octree to partition the faces and portals if I need to speed things up, though it seems to be fine with just having a big VBO of the world so long as I keep the textures small and use nearest magnification. My advice? Keep your poly count low, use the smallest textures you can get away with, write your truly performance critical code in C using the NDK (it'll be 10-20 times faster in my experience), carefully tune your texturing (you'll always be fill-bound with these chips) and deliver large batches to the GPU (don't try drawing face-by- face on anything!). Watch out for texture compression formats because while Droid uses PVRTC, every other phone uses ATITC. If you want to have the fastest texturing possible, you'll need to compress to both formats for your game and upload based on the extension. Otherwise just load textures in as RGB_565 bitmaps like pretty much every game does. If you look at demos like Armadillo roll, it'll show you what you can do with the environment but everything those guys did was using ATITC textures so it runs a little better than if you use bitmaps. There's a good chance they wrote a bunch of that natively as well, though it was out well before the NDK (but that didn't stop several people from building native libs). I'm getting similar lightmap performance to armadillo roll in the new game and the only native code I'm using right now is to interpolate verts. I'll probably move collisions into native space as well. On Dec 3, 10:13 pm, Ian Dunlop iandaviddun...@gmail.com wrote: Can anyone offer any advice? Thanks. On Dec 2, 3:26 am, Ian Dunlop iandaviddun...@gmail.com wrote: I'm experienced with openGL but not Android. I just started. I have some spinning cubes running on a Droid and I'm barely getting 30FPS. Should I be using GLSurfaceView to get the bestperformanceor is there a better way? Cheers, Ian Dunlop oeFun, Inc. -- 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
[android-developers] Re: Android Market Anti-Piracy
Nice discussion you have there... For the last few days I was thinking about how to implement protection technics for Android apps. One way is to go with alternative markets (like slideme) which provide online activation (slidelock in case of slideme). But more challenging (and interesting!) is to integrate protection with android's own market. I can think of three schemes: (1) Be able to supply an unique token to the user when he buys an app, and have him enter that token later in the app to activate it. (2) Somehow know which (by some id) phone is buying, and generate an app that will run only on that particular phone. (3) Generate an unique apk for each purchase and then let user through activation process which will tie an unique app id to the unique phone id. All this methods assume that app is protected (the interesting part) and can't be easily cracked. Now, as I understand options (2) and (3) is not available. We don't know anything about buying phone nor can we generate an apks. What about (1)? [I'm asking because I know nothing about commercial aspect of the market.] Or maybe there are other options? Let's discuss! Dmitry On 16 ноя, 17:12, AlexK kucherenko.a...@gmail.com wrote: Our company starts today anti-piracy initiative against piracy that already happened onAndroidMarket. We request all vendors and developers to support this initiative. Piracy become a threat for vendors that publishing application onAndroidMarket! It is not a joke, it is a real threat. Our last application publishing shows how bad is situation on theAndroidMarket. Only 20% of all installs are legal, other 80% are in piracy hands. Google does not provide any actions to stop piracy, so we as a vendor that provide software forAndroidMarket, have to think about protection measures. Piracy is threat that cannot be target easily and eliminated in one day. Only join of all vendors can help in anti- piracy. ArtfulBits company decide to start from today AndroidAnti-piracy Movement with main goal: protect vendors and punish piracy. Our next steps are: - Petition to Google with request to provide better anti-piracy protocols forAndroidMarket; - Collective anti-Google charge, from side of vendors that loose money due to Google security holes inAndroidMarketapplication distribution channel; - Public web service Black List, that helps all developer to check is there application installed on pirate phone; - Joining of the software vendors over that problem for finding better anti-piracy strategies; - Identification of the roots of piracy, that make possibleAndroidMarketsoftware leaking and contribution them to justice. A little later today we will open black-list database of devices, where was installed stolen version of applications. In addition, we will provide easy code for all developers that can be integrated into own application and during first start, check is phone in black list or not. Opened Anti-Piracy forum thread:http://www.artfulbits.com/Support Petition can be signed here:http://www.petitionspot.com/petitions/androidpiracy Stay tuned! Thanks. -- 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
[android-developers] Re: Android Market Anti-Piracy
Well, thanks for the info. I was prepared it all works like that :) And I came up with the following: (1) We obligate user to run application within N minutes after the purchase. (2) Every N minutes we update application on the market (each update effectively updates an unique id inside of application). (3) On the first run we activate an app (sending phone id to the server; server can deny activation). (4) And finally, we accept activations of the given app id only within N minutes. This effectively restricts lifetime of pirate copy to the N minutes. The downside is that we screwing up the whole update system of the market. The upside of that, in turn, is that maybe google will finally pay attention to the problem :) Dmitry On 24 ноя, 16:28, String sterl...@addressender.com wrote: On Nov 24, 10:15 am, Dmitry.Skiba dmitry.sk...@gmail.com wrote: (1) Be able to supply an unique token to the user when he buys an app, and have him enter that token later in the app to activate it. Short of (a) requiring the user to send you personal information, and (b) manually matching up that information with the cleared transactions on your Checkout account, I don't think this one's possible either. The problem is that there is no automatable way to distinguish a paid Market user from a pirate, and thus no way of knowing who you should supply said unique token to. The bottom line is, Google is the only one who can fix the Market's security. The rest of us just don't have the required tools. String -- 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
[android-developers] Re: Android Market Anti-Piracy
Huh? Regarding (1). That's almost the same as normal pc applications that require online activation. They either get cracked, someone creates a serial number generator, or people start posting stolen activation codes. Yes, it all looks like PC situation. Also, everything can be cracked, but cracking is magnitudes harder that copying, as it is now. Also Android allows for very tough protection schemes, like that being used in PC's protectors. And those are hard to crack. Activation code need not be generatable, it can be just GUID or something. And restricting number of activation for the given code gives as protection for the code sharing. Dmitry On 24 Nov, 11:15, Dmitry.Skiba dmitry.sk...@gmail.com wrote: Nice discussion you have there... For the last few days I was thinking about how to implement protection technics for Android apps. One way is to go with alternative markets (like slideme) which provide online activation (slidelock in case of slideme). But more challenging (and interesting!) is to integrate protection with android's own market. I can think of three schemes: (1) Be able to supply an unique token to the user when he buys an app, and have him enter that token later in the app to activate it. (2) Somehow know which (by some id) phone is buying, and generate an app that will run only on that particular phone. (3) Generate an unique apk for each purchase and then let user through activation process which will tie an unique app id to the unique phone id. All this methods assume that app is protected (the interesting part) and can't be easily cracked. Now, as I understand options (2) and (3) is not available. We don't know anything about buying phone nor can we generate an apks. What about (1)? [I'm asking because I know nothing about commercial aspect of the market.] Or maybe there are other options? Let's discuss! Dmitry On 16 ноя, 17:12, AlexK kucherenko.a...@gmail.com wrote: Our company starts today anti-piracy initiative against piracy that already happened onAndroidMarket. We request all vendors and developers to support this initiative. Piracy become a threat for vendors that publishing application onAndroidMarket! It is not a joke, it is a real threat. Our last application publishing shows how bad is situation on theAndroidMarket. Only 20% of all installs are legal, other 80% are in piracy hands. Google does not provide any actions to stop piracy, so we as a vendor that provide software forAndroidMarket, have to think about protection measures. Piracy is threat that cannot be target easily and eliminated in one day. Only join of all vendors can help in anti- piracy. ArtfulBits company decide to start from today AndroidAnti-piracy Movement with main goal: protect vendors and punish piracy. Our next steps are: - Petition to Google with request to provide better anti-piracy protocols forAndroidMarket; - Collective anti-Google charge, from side of vendors that loose money due to Google security holes inAndroidMarketapplication distribution channel; - Public web service Black List, that helps all developer to check is there application installed on pirate phone; - Joining of the software vendors over that problem for finding better anti-piracy strategies; - Identification of the roots of piracy, that make possibleAndroidMarketsoftware leaking and contribution them to justice. A little later today we will open black-list database of devices, where was installed stolen version of applications. In addition, we will provide easy code for all developers that can be integrated into own application and during first start, check is phone in black list or not. Opened Anti-Piracy forum thread:http://www.artfulbits.com/Support Petition can be signed here:http://www.petitionspot.com/petitions/androidpiracy Stay tuned! Thanks. -- 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
[android-developers] Re: Android Market Anti-Piracy
Yes, alternative shops is a solution. But not so good, as it complicates user experience. User must somehow become aware of this market, install it, and finally search for apps in both markets. On 24 ноя, 17:20, Juan Delgado zzzar...@gmail.com wrote: nor can we generate an apks I guess that if you implement your own shop (shelling through your own website) you could generate the apks server side upon request? Not sure this would completely fix the problem, but if you are not happy with the Android Market there's always the possibility to roll your own? If you think about it that's how most of the desktop software is sold these days. Juan On Tue, Nov 24, 2009 at 10:28 AM, String sterl...@addressender.com wrote: On Nov 24, 10:15 am, Dmitry.Skiba dmitry.sk...@gmail.com wrote: (1) Be able to supply an unique token to the user when he buys an app, and have him enter that token later in the app to activate it. Short of (a) requiring the user to send you personal information, and (b) manually matching up that information with the cleared transactions on your Checkout account, I don't think this one's possible either. The problem is that there is no automatable way to distinguish a paid Market user from a pirate, and thus no way of knowing who you should supply said unique token to. The bottom line is, Google is the only one who can fix the Market's security. The rest of us just don't have the required tools. String -- 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 -- Juan Delgado - Záratehttp://zarate.tvhttp://blog.zarate.tv -- 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
[android-developers] Re: Slow OpenGL on Samsung Galaxy - solution
It makes sense when you generalized it like that, but in this particular case the application gets put in software mode for asking for *less* capabilities. If it claims it needs a depth buffer when it doesn't, only then does it get the hardware acceleration. Exactly. Unfortunately I don't have Samsung Galaxy, so I don't know what configs are reported when only depth size of 16 is requested. Can someone please check it out? Maybe it will shed some light on the problem. BTW, here guys found that copying libhgl.so from G1 fixes the issue: http://androidforums.com/samsung-i7500/14611-opengl-working-galaxy-ii5.html Dmitry On 7 ноя, 06:02, Lance Nanek lna...@gmail.com wrote: if you ask for something that it doesn't support, the system will gracefully fallback to the software On Nov 6, 8:29 am, David Turner di...@android.com wrote: On Fri, Nov 6, 2009 at 1:00 AM, Dmitry.Skiba dmitry.sk...@gmail.com wrote: If your OpenGL game is running badly on Samsung Galaxy, you can try solution that we have found here: http://www.anddev.org/samsung_galaxy_odd_ogl_es_hardware_acceleration... In short, you need to setup your own EGLConfigChooser and choose depth size of 16. This is what we found. It seems that otherwise all rendering is done through software OpenGL. Now question to google guys: why is that? Because the GPU has limited capabilities, and if you ask for something that it doesn't support, the system will gracefully fallback to the software implementation ? Choosing the best configuration based on the hardware capabilities is quite a standard topic in OpenGL land. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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
[android-developers] Slow OpenGL on Samsung Galaxy - solution
If your OpenGL game is running badly on Samsung Galaxy, you can try solution that we have found here: http://www.anddev.org/samsung_galaxy_odd_ogl_es_hardware_acceleration_resolved-t8511.html In short, you need to setup your own EGLConfigChooser and choose depth size of 16. This is what we found. It seems that otherwise all rendering is done through software OpenGL. Now question to google guys: why is that? -- 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
[android-developers] Re: ADC2 Results Post
I've got three mails for 'Skiba PDF Reader', which didn't make it and none for 'Taps of Fire'. But then I checked spam folder, and woo-hoo! Congratulations! Your application 'Taps Of Fire' was selected by Android users as one of the top 20 in the Entertainment category! -- 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
[android-developers] Re: How to create a View from an external XML source?
Hm, yes, I was wrong. So, no official way of doing it, yet. Lets hack then :) I can suggest the following: put layout in a dummy project, generate .apk from it. Program would download this apk, install it, and then query xml resource via PackageManager. Dmitry On 15 сен, 15:52, Argy akri...@gmail.com wrote: Important: For performance reasons, view inflation relies heavily on pre-processing of XML files that is done at build time. Therefore, it is not currently possible to use LayoutInflater with an XmlPullParser over a plain XML file at runtime. So I guess it has to be a pre-processed XML file and not a plain XML file. That's bad news... it would be great if there was a workaround for this one... Now I have to parse the XML myself and create the layout... Any other suggestions? Thanks, Argy On Sep 15, 8:36 am, Dmitry.Skiba dmitry.sk...@gmail.com wrote: Hm, at a first glance this is possible: several LayoutInflater.inflate methods accept XmlPullParser, and you can certanly create one for an arbitrary Reader. Dmitry On 15 сен, 06:48, Argy akri...@gmail.com wrote: I'm just wondering if I'm able to create a View from an external XML source. As I was reading, you must place the XML layout inside the res/layout and when you compile it, you can load the layout by typing setContentView(R.layouts.my_layout). What if I have this XML layout online (on a website) and I want to create the layout on runtime? Is there any way to do this? Or I have to parse the XML and create the layout (hard-coded)? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: How to create a View from an external XML source?
Hm, at a first glance this is possible: several LayoutInflater.inflate methods accept XmlPullParser, and you can certanly create one for an arbitrary Reader. Dmitry On 15 сен, 06:48, Argy akri...@gmail.com wrote: I'm just wondering if I'm able to create a View from an external XML source. As I was reading, you must place the XML layout inside the res/layout and when you compile it, you can load the layout by typing setContentView(R.layouts.my_layout). What if I have this XML layout online (on a website) and I want to create the layout on runtime? Is there any way to do this? Or I have to parse the XML and create the layout (hard-coded)? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Showing force close / report dialog
You can use this technique: http://www.anddev.org/crashreporthandler-t6389.html In short, installing exception handler and lauching error report activity on crash. Add 'send' button and you're done. Dmitry On 9 сен, 01:16, Iroid irfan.f.k...@gmail.com wrote: Hello all, In my current application I want to show a dialog having Force Close and Report option at the time of Unhandled Exception. Could anyone please let me know how to have this dialog? right now if I change defaultExceptionHandler to mine It gets control but I am not able to show any dialog after that. I guess UI thread is already closed by the time handler gets control. Any pointers would of great help. Thanks in advance --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Using a hyperlink to do something
Well, actually you can embed a callback link to a TextView.
You just need special clickable span, which will call your methods
when clicked.
Here's an excerpt from my HTMLDialog class:
public void setHTML(String html) {
html=html.replaceAll((\r\n|\n),);
Spanned spannedHTML=Html.fromHtml(html);
SpannableString message=new SpannableString(spannedHTML.toString());
Object[] spans=spannedHTML.getSpans(0,spannedHTML.length
(),Object.class);
for (Object span: spans) {
int start=spannedHTML.getSpanStart(span);
int end=spannedHTML.getSpanEnd(span);
int flags=spannedHTML.getSpanFlags(span);
if (span instanceof URLSpan) {
URLSpan urlSpan=(URLSpan)span;
if (urlSpan.getURL().startsWith(CallbackSpan.PREFIX)) {
span=new CallbackSpan(urlSpan.getURL());
}
}
message.setSpan(span,start,end,flags);
}
m_message.setText(message);
}
protected void onCallback(String data) {
}
private final class CallbackSpan extends ClickableSpan {
public CallbackSpan(String url) {
int start=(url.startsWith(PREFIX)?PREFIX.length():0);
m_data=url.substring(start);
}
public void onClick(View view) {
onCallback(m_data);
}
public static final String PREFIX=callback:;
private String m_data;
}
and then you can put links of form a href='callback:mydata'callback
link/a anywhere in your document.
Don't forget to setup your TextView:
m_message.setLinksClickable(true);
m_message.setMovementMethod(LinkMovementMethod.getInstance());
Dmitry
On 4 сен, 01:04, Ken H hunt1...@gmail.com wrote:
Is it possible to use a hyperlink in android to do something other
than open a web page? I want to use a hyperlink in a TextView to
luanch a new activity, or something along those lines. I have a large
document and I want to let the user jump to references within the doc
(like a footnote or something). Can this be done?
Ken
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: Hmm... at last ADC2 is out of our way ... tell about your app and experience
Hi! My submissions are: * Taps Of Fire game http://code.google.com/p/tapsoffire (filled under Entertainment) * Skiba PDF Reader http://www.anddev.org/skiba_pdf_reader-t6122.html (Productivity/Tools) Dmitry On 2 сен, 18:27, Chris Hager metaka...@gmail.com wrote: I gave it a shot with MyMarket [1][2], a customizable overlay for the Android market, where users can bookmark, recommend, remove and filter as well as preview apps and games. I was thinking about the ADC2 since spring, waiting for a good enough idea to come up (and if at all). Four weeks ago my flatmate and I were talking about the Android market, and how boring it usually is to browse the apps and games listings (mainly because the popularity listings doesn't change a lot, and the by date listings are spammed by low-quality apps). We figured it would be a real improvement if users could simply remove items they don't want to see in the list anymore. We started working on the project and released the first version on 8. of August, followed by a ton of user feedback and great ideas which we had never thought about in first place. The next weeks have been a constant cycle of iterations, considering each and every feedback we received (we don't know what's best -- our users do!). Because of all those supporters we were able to integrate many new and anticipated features such as recommendations, my downloads with updates, quick filtering, etc. and have fixed a wide range of bugs which were detected in the first weeks. The last days we worked towards version 1.0, which we got finished a day before the ADC2 submission deadline. We released it on the Android market again and asked many users which sent us feedback previously for a quick test. We were able to fix 2 important bugs, and by now we are quite confident that MyMarket works as expected. We never could have come this far without all the help from our users -- credits go to them for thinking of many of the implemented ideas in first place! The last hours before the deadline we luckily had enough time to add one more (great) feature: displaying the number of user-votes in the recommendations. As most developers at this point we have been quite tired (no sleepless nights though) and hope not to have introduced no new bugs :P. I think our project works quite well -- we haven't received any feedback about new problems since we pushed the same version to the normal Android market. The ADC2 really pushed us to try to deliver a high-quality application, which works with all oddities (eg. screen rotations on the G1, etc.). We also asked the designers at glyfx to enhance our 2d icon to a 3d version, according to the (not really trivial) Android Icon Design Guidelines (great company btw.). It was a fun thought knowing that hundreds (if not thousands) of other teams were simultaneously working on their ADC-projects during the last days. Good luck to all the teams which submitted an entry! - Chris PS: I'm seriously looking forward to an announcement of Google, and hope they publish a list of all submissions. I find it a bit sad that the google-dev blog is not mentioning that the deadline is over, nor that the ADC2 site was updated (still says submit your apps today). Google could easily generate a bit more emotions and buzz in the whole Android community. [1]http://mymarket.cc [2]http://www.4feets.com/2009/09/mymarket-v10-submitted-to-the-adc2 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: How to read in a large array of chars, quickly?
In C++ char is one byte long, so memcpy works ok. But one-byte char is
a real pain when it comes to internationalization.
Java's jchar is like wchar_t in C++ and 2 bytes long.
If you are serious about this conversion and there is no way to avoid
it, and it is a real bottleneck, I suggest you to write JNI lib.
Dmitry
On Sep 2, 9:18 am, WoodManEXP woodman...@gmail.com wrote:
Hi Dianne,
Thank you for replying.
Frankly, I have been unable to figure out how to copy from a byte[] to
a char[] except with round-about methods like
1. Forming 2 bytes into a char using bit shifting and or'ing
2. Using the java.nio classes (which are S L O W) if you need to do
lots of transfers like say 200,000 or more.
In any event the Android seems really slow becasue a block like
for(int i=0; i100;i++) {
c[i] = b[i]
}
takes like 20-25 seconds to execute (On Intel Pentium, eq #, such a
thing executes in a flash).
In C++ or even C# you could simply code
char[] c = new char[100];
.read((char *)c, 2*100);
And it would just lay in the binary data in the array.
How can such a thing be accomplished for the Android/Java?
ANY ideas you can pass along are greatly appreciated!
On Sep 1, 8:44 pm, Dianne Hackborn hack...@android.com wrote:
How long does it take to just copy from a byte[] to your own char[] in code?
On Tue, Sep 1, 2009 at 5:13 PM, WoodManEXP woodman...@gmail.com wrote:
This is sort of a java question too…
How to read in a large array of chars, quickly?
I have a file on the /sdcard/ with a million chars (2 bytes each) that
I would like to read in quickly. It is a binary file written from
another system and I cannot change it.
It can be read into a byte[] array extremely quickly with a statement
like
// dInStream is an open DataInoutStream
// This is a really, really fast operation on Android
byte[] rBuffer = new byte[2*100]; // Yes I know this is a lot for
Android
numBytesRead = dInStream.read(rBuffer, 0, 2*100);
But then to get the data into a char[] array is evading me.
I have tried lots of stuff from java.nio like ByteBuffers converting
to CharBuffers and the get methods and they will do the conversion but
they are so very S L O W.
It takes 1 sec to do the dInStream.read call and then like 30
seconds to walk over the wraped ByteArray.asCharBuffer using the
various get methods.
For a sec I thought ByteBuffer.asCharBuffer.array() was going to save
the day. But it exceptions out because the wrap of the byte[] array is
owned by the ByteBuffer, not the CharBuffer.
Is there any way just to do the dInStream.read directly into the char
array or maybe “cast” the byte[] array to a char[] array?
Thanks in advance for any help!
--
Dianne Hackborn
Android framework engineer
hack...@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.- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: 5 mins to ADC II submission deadline - so what is your submission?
My submission was a Frets Of Fire port for Android: http://code.google.com/p/tapsoffire On Sep 1, 1:57 pm, Dollars 5 dollars5ad...@gmail.com wrote: Hello All, Best of luck to all submissions, so what was your submission? We were able to submit only a partner application which I cannot reveal due to NDA. But our submission was unsubmitted as we were unable to finish some critical things.. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: SoundPool bug
Hm. I think that getStreamVolume() and values expected by play() are
unrelated. getStreamVolume() returns integer value in range
[0,getMaxStreamVolume], while SoundPool.play expects float value in
range [0,1). You should try passing 0.99f to play(), so the resulting
volume of sound will be 0.99f*AudioManager.getStreamVolume().
A note about 0.99f - my last experience with SoundPool was that it
doesn't like 1.0s, it just mutes on that volume, while on 0.99f it
plays loud.
Dmitry
On 3 сен, 01:18, Illidane illid...@gmail.com wrote:
Hi all!
Here is my code:
public static final int SOUND_CLICK = 1;
public static final int SOUND_DEATH = 2;
public static SoundPool soundPool;
public static HashMapInteger, Integer soundPoolMap;
...
soundPool = new SoundPool(4, AudioManager.STREAM_MUSIC, 100);
soundPoolMap = new HashMapInteger, Integer();
soundPoolMap.put(SOUND_CLICK, soundPool.load(Context, R.raw.click,
1));
soundPoolMap.put(SOUND_DEATH, soundPool.load(Context, R.raw.death,
1));
...
public static void playSound(int sound)
{
AudioManager mgr = (AudioManager)Context.getSystemService
(Context.AUDIO_SERVICE);
int streamVolume = mgr.getStreamVolume
(AudioManager.STREAM_MUSIC);
soundPool.play(soundPoolMap.get(sound), streamVolume,
streamVolume, 1, 0, 1f);
}
After loading this sounds I'm waiting few seconds and than start
playing them. Usually all is fine, but sometimes one of this sounds
( even both ) just disappear.
What's the problem with it?
Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: Architecture dilema
You can also use full screen non-transparent dialogs. They look like activities, but are simpler to handle. For example for Settings screen of a game I would (and in fact, do) go with dialogs. Dmitry On 20 авг, 13:40, loctarar andrei.bu...@gmail.com wrote: Hello! This may sound a little silly. Let's say I want to build a game with a menu, an options screen, a form screen (for the user to insert some data) and the game screen. The usual approach would be to have an activity for each case (correct me if I'm wrong). What if I do another thing... and code four views for each case and swap them using setContentView() in the same activity? Suppose that I'll override the onSaveInstanceState() to save the state of the views in all the four cases. What is the disadvantage in this approach besides having a huge activity that I'm sure it gets closed every time the system is low in memory? I haven't tested it yet, but I didn't find anything in the docs that could stop this approach to work. The reasons for avoiding the usual implementation is that I need to convert an application from J2ME and having multiple activities raises some difficulties in the porting process. Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Bad OpenGL Emulation?
Hmm, it works for me, both with textured quad (VBO and not) and with draw_texture extension. Dmitry On 20 авг, 10:58, Robert Green rbgrn@gmail.com wrote: What's everyone's experience with this? I'm developing a new game and have been having inconsistencies between the device and emulator. The biggest one for me right now is that the elements I draw with an orthographic projection work correctly on the device, but are 1/2 the size on the emulator. I've checked and rechecked the code 100 times and I'm positive I've done it right but am confused as to why I'm seeing that result. I suppose I could go forward doing ALL testing on a device - and I may have to, seeing that the emulator's frame rate is horribly slow - but I was hoping that I could do some of the work on it at least. Do you guys do all your opengl on a G1 or do you actually try to use the emulator for any of it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Bad OpenGL Emulation?
No, sorry, draw_texture is not working in emulator (and I didn't checked why or how to avoid it). Dmitry On 20 авг, 21:37, Dmitry.Skiba dmitry.sk...@gmail.com wrote: Hmm, it works for me, both with textured quad (VBO and not) and with draw_texture extension. Dmitry On 20 авг, 10:58, Robert Green rbgrn@gmail.com wrote: What's everyone's experience with this? I'm developing a new game and have been having inconsistencies between the device and emulator. The biggest one for me right now is that the elements I draw with an orthographic projection work correctly on the device, but are 1/2 the size on the emulator. I've checked and rechecked the code 100 times and I'm positive I've done it right but am confused as to why I'm seeing that result. I suppose I could go forward doing ALL testing on a device - and I may have to, seeing that the emulator's frame rate is horribly slow - but I was hoping that I could do some of the work on it at least. Do you guys do all your opengl on a G1 or do you actually try to use the emulator for any of it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Bad OpenGL Emulation?
Ha, nice bug. I'm using floats though. Why do you use fixed point? Is it (much) faster than float? Dmitry On 21 авг, 00:50, Robert Green rbgrn@gmail.com wrote: I found the problem with the orthographic projection and documented it here -http://groups.google.com/group/android-developers/browse_thread/threa... Emulator performance is still really bad, though. I've started to use the device for everything now because the emulator is just too slow for testing a game. On Aug 20, 9:38 am, Dmitry.Skiba dmitry.sk...@gmail.com wrote: No, sorry, draw_texture is not working in emulator (and I didn't checked why or how to avoid it). Dmitry On 20 авг, 21:37, Dmitry.Skiba dmitry.sk...@gmail.com wrote: Hmm, it works for me, both with textured quad (VBO and not) and with draw_texture extension. Dmitry On 20 авг, 10:58, Robert Green rbgrn@gmail.com wrote: What's everyone's experience with this? I'm developing a new game and have been having inconsistencies between the device and emulator. The biggest one for me right now is that the elements I draw with an orthographic projection work correctly on the device, but are 1/2 the size on the emulator. I've checked and rechecked the code 100 times and I'm positive I've done it right but am confused as to why I'm seeing that result. I suppose I could go forward doing ALL testing on a device - and I may have to, seeing that the emulator's frame rate is horribly slow - but I was hoping that I could do some of the work on it at least. Do you guys do all youropenglon a G1 or do you actually try to use the emulator for any of it? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Simply touching screen reduces fps
Thank you all for replying. Sleeping in onTouchEvent is an interesting idea, I will try that. But results in my first post where obtained while *not moving* finger at all. Well, maybe there are fluctuations in determining my finger's position, and events were arriving nevertheless. I will check that tomorrow. Dmitry On 10 авг, 23:38, sahn0 dmitry.sk...@gmail.com wrote: Yes, it is. Try SpriteMethodTest, set 100 sprites, select OpenGL / Use VBO, let it run for a while. You will get something around 20ms / 50 fps. Now run it second time, and simply touch screen while test is running. You will get something around 35ms / 29 fps. So it is 15 ms difference. As I understand, the answer is simple - it is that dispatcher thread running with THREAD_PRIORITY_URGENT_DISPLAY priority. Setting THREAD_PRIORITY_URGENT_DISPLAY priority (will it work on non- ADP firmware?) on renderer thread yields 30 ms / 33 fps. Are there any other workarounds? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Process.setThreadPriority() high priorities
This issue is pretty important for my game, as simply changing the priority to a higher value makes it (much) more comfortable to play. Can I rely to this effect or should I go and cut my geometry in half? (again...) Google guys, please answer :) Dmitry On 13 авг, 01:40, Dmitry.Skiba dmitry.sk...@gmail.com wrote: I'm curious, what does remark Applications can not normally change to this priority for some priorities in android.os.Process mean? I can successfully change thread priority to THREAD_PRIORITY_URGENT_DISPLAY or THREAD_PRIORITY_AUDIO (and I can confirm the effect). But I use ADP firmware, maybe on 'normal' G1 this method will throw? Or is it just an documentation glitch? If not, should we absolutely not use these priorities, or we can try, but be prepared for an exception? Dmitry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Process.setThreadPriority() high priorities
Ok, thank you, that is what I wanted to hear :) Of course my case is not just 'this thing is slow', I need to play two perfectly synced tracks and render opengl scene. I too discourage people from using this priorities unless absolutely necessary. Dmitry On 13 авг, 23:29, Dianne Hackborn hack...@android.com wrote: I believe at the time the doc was written, the intention was to limit priorities, but this was never done. The priorities you mention (urgent display and audio) are NOT for use by applications, except in very special cases (audio can make sense for time-critical audio processing code that can provide strong guarantees about the amount of CPU it will take per time slice). Please don't use these for regular applications. If they start getting abused and impacting the overall system, we will need to do something in the future to restrict what apps can do. :} On Thu, Aug 13, 2009 at 6:17 AM, Dmitry.Skiba dmitry.sk...@gmail.comwrote: This issue is pretty important for my game, as simply changing the priority to a higher value makes it (much) more comfortable to play. Can I rely to this effect or should I go and cut my geometry in half? (again...) Google guys, please answer :) Dmitry On 13 авг, 01:40, Dmitry.Skiba dmitry.sk...@gmail.com wrote: I'm curious, what does remark Applications can not normally change to this priority for some priorities in android.os.Process mean? I can successfully change thread priority to THREAD_PRIORITY_URGENT_DISPLAY or THREAD_PRIORITY_AUDIO (and I can confirm the effect). But I use ADP firmware, maybe on 'normal' G1 this method will throw? Or is it just an documentation glitch? If not, should we absolutely not use these priorities, or we can try, but be prepared for an exception? Dmitry -- Dianne Hackborn Android framework engineer hack...@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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Process.setThreadPriority() high priorities
I'm curious, what does remark Applications can not normally change to this priority for some priorities in android.os.Process mean? I can successfully change thread priority to THREAD_PRIORITY_URGENT_DISPLAY or THREAD_PRIORITY_AUDIO (and I can confirm the effect). But I use ADP firmware, maybe on 'normal' G1 this method will throw? Or is it just an documentation glitch? If not, should we absolutely not use these priorities, or we can try, but be prepared for an exception? Dmitry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: OpenGL texture corrupted when there's an interruption.
I don't see gl.glEnableClientState(GL10.{GL_VERTEX_ARRAY,
GL_TEXTURE_COORD_ARRAY}) in your code.
Also don't forget to call GLSurfaceView's onPause() and onResume()
methods (in corresponding Activity methods).
Dmitry
On Aug 11, 11:42 am, alucard20004 alucard20...@gmail.com wrote:
I took the source from API demos (TriangleRenderer.java)
Here's the code on how textures are loaded in onSurfaceCreated():
/*
* Create our texture. This has to be done each time the
* surface is created.
*/
int[] textures = new int[1];
gl.glGenTextures(1, textures, 0);
mTextureID = textures[0];
gl.glBindTexture(GL10.GL_TEXTURE_2D, mTextureID);
gl.glTexParameterf(GL10.GL_TEXTURE_2D,
GL10.GL_TEXTURE_MIN_FILTER,
GL10.GL_NEAREST);
gl.glTexParameterf(GL10.GL_TEXTURE_2D,
GL10.GL_TEXTURE_MAG_FILTER,
GL10.GL_LINEAR);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_WRAP_S,
GL10.GL_CLAMP_TO_EDGE);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_WRAP_T,
GL10.GL_CLAMP_TO_EDGE);
gl.glTexEnvf(GL10.GL_TEXTURE_ENV, GL10.GL_TEXTURE_ENV_MODE,
GL10.GL_REPLACE);
InputStream is = mContext.getResources()
.openRawResource(R.drawable.robot);
Bitmap bitmap;
try {
bitmap = BitmapFactory.decodeStream(is);
} finally {
try {
is.close();
} catch(IOException e) {
// Ignore.
}
}
GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0);
bitmap.recycle();
And here's how I mapped my texture:
/
public void onDrawFrame(GL10 gl) {
//Init
gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT);
gl.glMatrixMode(GL10.GL_MODELVIEW);
gl.glLoadIdentity();
//Draw Cube
gl.glPushMatrix();
gl.glTranslatef(0, 0, -2);
gl.glRotatef(azimuthZ, 0, 0, 1); //azimuthZ is
from the sensors
//texBuff and boxBuff are texture and box coordinates
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texBuff);
gl.glVertexPointer(3, GL10.GL_FLOAT, 0, boxBuff);
//top
gl.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4);
//bottom
gl.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 4, 4);
// followed by left, right, front and back
sides...
gl.glPopMatrix();
/
Problem:
1. The box is rendering normally.
2. I press 'Call' button, the Dialer app comes up.
3. I press 'Back' button. My box app comes up.
4. The texture became corrupted...
- This does not happen if I press back while in the box app, and re-
launch the box app.
- This also does not happen in the Textured Triangle in API demos.
I've no idea what did I do wrong. -_-
Thank you in advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: OpenGL leaking garbage
OK, you've made it absolutely clear that non-direct buffers are definately a no-no :) Anyway, I will stick to VBOs (which, as Jack explained, do not need direct buffers at all). I hope this thread will be helpful to others as much as it was for me. Dmitry On 7 авг, 01:07, fadden fad...@android.com wrote: On Aug 5, 8:17 pm, Dmitry.Skiba dmitry.sk...@gmail.com wrote: By the way, to guarantee that non-direct buffer will not be moved be GC one can hack up a JNI lib wich will 'pin' needed buffers for the lifetime of an application :) Actually, you can't. The VM has the option to pin or copy the data in the virtual heap. If you'd like to see this in action, try this (requires emulator or rooted device): % adb shell setprop dalvik.vm.checkjni true % adb shell setprop dalvik.vm.jniopts forcecopy % adb shell stop ; adb shell start The JNI forcecopy mode forces the VM to make a copy of data rather than pin it in place. This is less efficient due to the additional data copying, but it does allow the GC to move memory around, and will expose situations where pointers are being kept inappropriately. The forcecopy stuff also adds guard regions around the allocated blocks to check for overruns, fills the memory with a garbage pattern before freeing it to expose use-after-free, and checksums read-only stuff like String data to ensure code is not inadvertently modifying it. If you're not using direct buffers where they are required, your application will likely freak out when forcecopy is enabled. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: OpenGL leaking garbage
Good news, gyus!
I've found a way to get rid of garbage collection!
The receipt is simple (and ironic): do not use allocateDirect(), use
allocate(). And use only ByteBuffer, not FloatBuffer, IntBuffer, etc.
- using asFloatBuffer() on non-direct ByteBuffer will result in crash
in libhgl. (I'm too lazy to create an issue for that.)
E.g. this code:
ByteBuffer vbb = ByteBuffer.allocateDirect(vertices.length*4);
vbb.order(ByteOrder.nativeOrder());
mVertexBuffer = vbb.asIntBuffer();
mVertexBuffer.put(vertices);
mVertexBuffer.position(0);
should be
ByteBuffer vbb = ByteBuffer.allocate(vertices.length*4);
vbb.order(ByteOrder.nativeOrder());
for (int vertex: vertices) {
mVertexBuffer.putInt(vertex);
}
mVertexBuffer.position(0);
and voila, no garbage collections on ADP 1.5 firmware.
Please test and report your results here.
Dmitry
On 16 июл, 21:33, PaulT dr.paul.thomas.android.st...@googlemail.com
wrote:
Hello everybody,
I've created a simple OpenGL app and created a rendering class which
implements GLSurfaceView.Renderer. All it does is draw 100 triangles
(NUM_OBJECTS = 100) on the screen and move them about, bouncing off
the edges. The projection is glOrtho2D and there is no z-buffer. I'm
running this on a G1 with continuous redraw enabled.
Here is the onDrawFrame method:
public void onDrawFrame(GL10 gl) {
gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
for (n = 0; n NUM_OBJECTS; n++) {
gl.glPushMatrix();
gl.glTranslatef(posX[n], posY[n], 0);
gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vBuffer);
gl.glDrawElements(GL10.GL_TRIANGLES, 3, GL10.GL_UNSIGNED_SHORT,
iBuffer);
gl.glPopMatrix();
posX[n] += xa[n];
posY[n] += ya[n];
if (posX[n] viewW || posX[n] 0) {
xa[n] = -xa[n];
}
if (posY[n] viewH || posY[n] 0) {
ya[n] = -ya[n];
}
}
}
It's pretty simple stuff just to get an idea of the device
performance. Note that I am not leaking any garbage in this method.
If we look at the logs while this is running,
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 153ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 156ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 157ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 155ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 156ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 156ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 157ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 155ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 152ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 155ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 150ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 155ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 153ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 155ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 157ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 155ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 151ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 159ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 155ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 156ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 153ms
D/dalvikvm( 3085): GC freed 21842 objects / 524304 bytes in 158ms
D/dalvikvm( 3085): GC freed 21840 objects / 524256 bytes in 151ms
Every few seconds, the garbage collector has a bit of a tidy up. If
we look at the frame rate, it is averaging out to be around 56Hz. I
speculate that the system can keep up with the 60Hz vertical sync just
fine until it needs to collect garbage.
Nothing else is running so this stuff is definitely coming from this
app. Unfortunately it causes the display to pause briefly (160ms is
about 10 frames) so would not be acceptable in an interactive game.
Does anybody know what causes this (something in the OpenGL code?) and
can it be avoided?
Thanks for any help.
Paul.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: OpenGL leaking garbage
Paul, I forgot the assignment, mVertexBuffer=vbb; :)
Yes, it crashes because as I suspect, GL's JNI code can't deal with
XXXBuffer wrapping non-direct ByteBuffer. Thats why you should avoid
using anything except ByteBuffer when you use allocate(). Luckily
ByteBuffer has all the needed methods, putFloat, putInt, etc.
Dmitry
PS. As my investigations showed, this trick eliminates *some* of the
object allocations, but not all. For other allocations you should
check your code. Simple System.gc() on top of onDrawFrame() will tell
you how many objects were created in the last frame.
On 5 авг, 20:30, Paul Thomas
dr.paul.thomas.android.st...@googlemail.com wrote:
Dimitry,
2009/8/5 Dmitry.Skiba dmitry.sk...@gmail.com:
should be
ByteBuffer vbb = ByteBuffer.allocate(vertices.length*4);
vbb.order(ByteOrder.nativeOrder());
for (int vertex: vertices) {
mVertexBuffer.putInt(vertex);
}
mVertexBuffer.position(0);
Where are you getting mVertexBuffer from? ByteBuffer mVertexBuffer =
ByteBuffer.allocate(vertices.length*4); ?
I tried switching to allocate from allocateDirect, but it crashes :-(
If you are using integers in your vertex buffer, how are you setting
up the vertex pointer?
Thanks
Paul.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: OpenGL leaking garbage
Thank you Jack for your explanation. I am using VBOs now, so I can easily switch to direct buffers. By the way, what is the limit for VBO buffers? (if there is one) And one more thing. In my code I am drawing a 1008-vertex geometry using glDrawArrays(GL_TRIANGLES). Weird thing is that it draws model + garbage when I pass 1008 as 'count' argument to glDrawArrays, and draws correctly when I pass 1008/3. I believe 1008 is the correct value to pass, but it just not working that way. In many demos there are calls to glDrawArrays with GL_TRIANGLES, but they only draws few vertices (36 for example). I suspect my 1008 vertices (and normals) do not fit in some sort of cache, and code draws them differently, and somewhere it multiplies 'count' by 3 (hence drawing garbage when 1008 is passed). This behaviour shows up on the emulator and the G1. (glDrawElements has the same behaviour when indices are simple array [0,count-1].) Dmitry On 6 авг, 02:14, Jack Palevich jack.palev...@gmail.com wrote: Hi -- I work on the Java Open GL ES bindings for Android. Fadden asked me to chime in here. Please don't use indirect buffers with OpenGL ES -- indirect buffers are not supported, and your code will break, both on current and especially on future versions of Android. Let me see if I can explain what's going on: (In my message below I'm going to use the code-name Cupcake for the current Android release and the code-name Donut for the upcoming release.) There are several bugs in the way Android currently handles java.nio.Buffer objects passed to OpenGL ES APIs: 1) In all releases up to and including Cupcake, the implementation allocates PlatformAddress objects every time a direct buffer's base address is calculated. (In other words, when any glXXXPointer function is called.) This leads to garbage collections, even in programs that don't appear at the API level to be allocating any new objects. (You can use a heap analysis tools to watch these PlatformAddress objects being created.) 2) The OpenGL ES APIs that take buffers are only supposed to take direct buffers, but this runtime check was accidentally omitted from all releases up to and including Cupcake. The problem with non-direct buffers is that their data can be moved by the Java runtime while the OpenGL driver is holding a pointer to them, which means that OpenGL driver ends up reading the wrong data, or even trying to read no- longer-allocated memory. To fix problem #2, the Donut system software release will start enforcing the direct buffer requirement. To keep existing, mostly- working OpenGL applications from breaking, we are going to add a compatibility shim in Donut: If your application is compiled against the Cupcake or earlier SDK, then we won't throw an exception if you use a non-direct buffer with OpenGL ES. You app will still suffer from the same occasionally crashes or renders incorrectly bug that it currently suffers from under Cupcake, but things won't be any worse. We will print out an error message to the log so at least you have a way of detecting that your app is using OpenGL incorrectly. If your application is compiled with the Donut SDK, it will throw a runtime exception if you try to use a non-direct buffer with an OpenGL ES API. (The reasoning is that if you are compiling using the Donut SDK, then you can take the time to fix your app.) OK, so what's a poor developer to do now, before the Donut system software? You could try using indirect buffers, in which case you will get code that doesn't GC very much, but also occasionally renders incorrectly or crashes. Or you can use direct buffers, and live with more GCs. I recommend using direct buffers, because I think it's better to have occasional GC hiccups than crashes. And once Donut is released the GC disadvantage should be fixed. On Aug 5, 11:01 am, fadden fad...@android.com wrote: On Aug 4, 11:09 pm, Dmitry.Skiba dmitry.sk...@gmail.com wrote: I've found a way to get rid of garbage collection! The receipt is simple (and ironic): do not use allocateDirect(), use allocate(). And use only ByteBuffer, not FloatBuffer, IntBuffer, etc. - using asFloatBuffer() on non-direct ByteBuffer will result in crash in libhgl. (I'm too lazy to create an issue for that.) I'm pretty sure this will break in the next release. My (very limited) understanding is that direct buffers are supposed to be required, but Android wasn't enforcing their use. This situation has been corrected. The allocations reduced by 8767 (earlier in the thread) were Harmony PlatformAddress objects, which are only associated with direct buffers. So it makes sense that your change would cut the allocations; just be aware that it may stop working. (I'll ask one of the GL folks to check me on this.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers
[android-developers] Re: OpenGL leaking garbage
By the way, to guarantee that non-direct buffer will not be moved be GC one can hack up a JNI lib wich will 'pin' needed buffers for the lifetime of an application :) On 6 авг, 10:07, Dmitry.Skiba dmitry.sk...@gmail.com wrote: Thank you Jack for your explanation. I am using VBOs now, so I can easily switch to direct buffers. By the way, what is the limit for VBO buffers? (if there is one) And one more thing. In my code I am drawing a 1008-vertex geometry using glDrawArrays(GL_TRIANGLES). Weird thing is that it draws model + garbage when I pass 1008 as 'count' argument to glDrawArrays, and draws correctly when I pass 1008/3. I believe 1008 is the correct value to pass, but it just not working that way. In many demos there are calls to glDrawArrays with GL_TRIANGLES, but they only draws few vertices (36 for example). I suspect my 1008 vertices (and normals) do not fit in some sort of cache, and code draws them differently, and somewhere it multiplies 'count' by 3 (hence drawing garbage when 1008 is passed). This behaviour shows up on the emulator and the G1. (glDrawElements has the same behaviour when indices are simple array [0,count-1].) Dmitry On 6 авг, 02:14, Jack Palevich jack.palev...@gmail.com wrote: Hi -- I work on the Java Open GL ES bindings for Android. Fadden asked me to chime in here. Please don't use indirect buffers with OpenGL ES -- indirect buffers are not supported, and your code will break, both on current and especially on future versions of Android. Let me see if I can explain what's going on: (In my message below I'm going to use the code-name Cupcake for the current Android release and the code-name Donut for the upcoming release.) There are several bugs in the way Android currently handles java.nio.Buffer objects passed to OpenGL ES APIs: 1) In all releases up to and including Cupcake, the implementation allocates PlatformAddress objects every time a direct buffer's base address is calculated. (In other words, when any glXXXPointer function is called.) This leads to garbage collections, even in programs that don't appear at the API level to be allocating any new objects. (You can use a heap analysis tools to watch these PlatformAddress objects being created.) 2) The OpenGL ES APIs that take buffers are only supposed to take direct buffers, but this runtime check was accidentally omitted from all releases up to and including Cupcake. The problem with non-direct buffers is that their data can be moved by the Java runtime while the OpenGL driver is holding a pointer to them, which means that OpenGL driver ends up reading the wrong data, or even trying to read no- longer-allocated memory. To fix problem #2, the Donut system software release will start enforcing the direct buffer requirement. To keep existing, mostly- working OpenGL applications from breaking, we are going to add a compatibility shim in Donut: If your application is compiled against the Cupcake or earlier SDK, then we won't throw an exception if you use a non-direct buffer with OpenGL ES. You app will still suffer from the same occasionally crashes or renders incorrectly bug that it currently suffers from under Cupcake, but things won't be any worse. We will print out an error message to the log so at least you have a way of detecting that your app is using OpenGL incorrectly. If your application is compiled with the Donut SDK, it will throw a runtime exception if you try to use a non-direct buffer with an OpenGL ES API. (The reasoning is that if you are compiling using the Donut SDK, then you can take the time to fix your app.) OK, so what's a poor developer to do now, before the Donut system software? You could try using indirect buffers, in which case you will get code that doesn't GC very much, but also occasionally renders incorrectly or crashes. Or you can use direct buffers, and live with more GCs. I recommend using direct buffers, because I think it's better to have occasional GC hiccups than crashes. And once Donut is released the GC disadvantage should be fixed. On Aug 5, 11:01 am, fadden fad...@android.com wrote: On Aug 4, 11:09 pm, Dmitry.Skiba dmitry.sk...@gmail.com wrote: I've found a way to get rid of garbage collection! The receipt is simple (and ironic): do not use allocateDirect(), use allocate(). And use only ByteBuffer, not FloatBuffer, IntBuffer, etc. - using asFloatBuffer() on non-direct ByteBuffer will result in crash in libhgl. (I'm too lazy to create an issue for that.) I'm pretty sure this will break in the next release. My (very limited) understanding is that direct buffers are supposed to be required, but Android wasn't enforcing their use. This situation has been corrected. The allocations reduced by 8767 (earlier in the thread) were Harmony PlatformAddress objects, which are only associated with direct buffers
[android-developers] Re: OpenGL leaking garbage
Yes, and this is because they do not use any GL10 methods. All game is one big jni lib with tiny wrapper of java classes ontop. The only question is: how did they manage to access gl from jni? Dmitry On 1 авг, 00:15, Nightwolf mikh...@gmail.com wrote: I think things aren't that bad. Take a look at Armadillo Roll. Checking DDMS showed that GC was't invoked during watching demo flyby and playing the game for 3-4 minutes. On Jul 29, 12:57 pm, Paul Thomas dr.paul.thomas.android.st...@googlemail.com wrote: Thanks for your helpful comments, everybody. 2009/7/28 smartpixgames smartpix.ga...@gmail.com: In general, it's very frustrating that we have a good hardware useful for gaming, but a bad realization of very critical things for 3D-gaming and now it's almost impossible to develop quality 3D-games for Android... Yes, agree completely. The hardware is quite fast, and we want to encourage everybody to program in Java for cross-platform compatibility. I think there needs to be a fast rendering path on OpenGL ES 1.0 without needing extensions as support for 1.1 is not guaranteed. Seems clear that gl.glVertexPointer / gl.glDrawElements must be fast as this is the obvious combination that anybody will try first. Could somebody at Google bump the priority of this a bit? It looks as though that patch might still need work according to the code reviews. Thanks Paul. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
