[android-developers] Simply touching screen reduces fps
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: Getting source under Windows (from web interface).
Also, as I just discovered, there is that lovely 'snapshot' link, in 'tree' view. Which results in .tar.gz archive. On 22 окт, 20:23, Anm <[EMAIL PROTECTED]> wrote: > There is a port of git in Cygwin. It works just fine. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Getting source under Windows (from web interface).
As we all know, Google released Android's source today. But you can't get source if you are Windows user. Luckily, there is a web interface (http://git.source.android.com), which allows you to browse all files. So I wrote very simple program that parses htmls, collects links and downloads files. Get it here: http://android4me.googlecode.com/files/GetWebGit.jar Usage is very simple: GetWebGit E.g.: GetWebGit.jar platform/frameworks/base.git C:\Android\framework You can also download any subfolder of any project. This requires more work, though - go to the web interface, copy 'tree' folder's link and supply it as argument. E.g.: GetWebGit.jar http://git.source.android.com/?p=platform/build.git;a=tree;f=core/combo;h=2d6d494c1c5fad17496d32664d2ce36a9bd4e22e;hb=HEAD core/combo --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] _SAVE_FLAGs and Canvas.save(int saveFlags)
I need a clarification on which _SAVE_FLAG values can go into save(int saveFlags) method. As I understand, I can specify only two of them - MATRIX_SAVE_FLAG and CLIP_SAVE_FLAG. What about other values? Are they used internally? Maybe they should be private then? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Bitmap on sdcard & decodestream
Maybe it is jpg format that causing problems? Try converting images to
png.
On 30 сент, 16:17, Matteo Crippa <[EMAIL PROTECTED]> wrote:
> Easy i was playing with a little app i'm developing but i've just
> found a little problem... let's explain me it...
>
> I created a sdcard and inside it I placed some jpg files.
>
> So my data path is something like:
>
> /sdcard/app/img/1.jpg
> /sdcard/app/img/2.jpg
> /sdcard/app/img/3.jpg
> /sdcard/app/img/4.jpg
> [...]
> /sdcard/app/img/n.jpg
>
> Now I want to create a gallery app to show out these files, I looked
> at demo srcs by android sdk, but they always use imgs from
> resources...
>
> I decided to try using Bitmapfactory.decodeFile and also
> Bitmapfactory.decodestream but both seems not to work fine returning a
> NullPointerException
>
> Here you are a little snippet of my app:
>
> Java:
>
> for(int i=0;i {
> Log.d(""+i,"/sdcard/app/img/"+imgsTokens[i]
> +".jpg");
> try
> {
> FileInputStream is = new FileInputStream(new
> File("/sdcard/app/img/"+imgsTokens[i]+".jpg"));
> BufferedInputStream bis = new
> BufferedInputStream(is);
> photos[i] = BitmapFactory.decodeStream(is);
> bis.close();
> is.close();
>
> //photos[i] = BitmapFactory.decodeFile("/
> sdcard/app/img/"+imgsTokens[i]+".jpg");
> }
> catch(Exception e)
> {
> e.printStackTrace();
> }
> }
>
> any idea how to fix?
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Decompile android.jar - RuntimeException("Stub!") - SDK 1.0
Oh, yes, that "Stub!" thing :)
I hope this doesn't mean that there will be no source code release for
SDK... Otherwise, why "stubbize" android.jar?
BTW, decompilation is illegal, and is prohibited by license agreement.
On 25 сент, 18:32, friedger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I used to have a look at the classes in android.jar using JadClipse.
>
> Since SDK 1.0 I only get class method looking like
>
> public void something(...){
> throw new RuntimeException("Stub!");
>
> }
>
> 1. Is there another possibility to decompile/understand the android
> classes?
> 2. How did you manage to do that? Code obfuscation is also an issue
> for us.
>
> Friedger
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: drawLine is broken
Thanks for the explanation. Now I need to comprehend it :) On 11 сент, 20:28, Mike Reed <[EMAIL PROTECTED]> wrote: > /* oops, the rect example I gave is for (0,0) (2,0) */ > > On Sep 11, 2008, at 9:27 AM, Mike Reed wrote: > > The general confusion is that the android graphics geometry is center- > line based, and consistent at all matrix transformations, while J2ME > linedrawing is more "pen" based. > > As an example, when android draws a line, it basically constructs a > rectangle about the line, by moving parallel to the line by 1/2 the > strokeWidth. If there is no fancy Join (e.g. Square or Round), no > outset is performed on the line's ends. So for the line (0,0) (0,2), > it constructs the rectangle > > // assuming the strokeWidth is 1.0 > left = 0 > top = -1/2 > right = 2 > bottom = 1/2 > > and then tries to fill the rectangle, using the standard of rounding > each coordinate to an int via (int)(coord + 0.5) // for positive coords > > That said, in your example, the strokeWidth is 0, which is a special > value meaning hairline. This is pretty close to 1.0, but will draw > slightly differently at times, but much faster. (aside: hairline > stroking always draws 1-pixel wide, regardless of the matrix on the > canvas). > > Stroking rectangles in hairline mode does a little extra work to be > nice to try to hit all of the corners, even if the normal hairline > drawLine path would have missed it. > > But back to center-line geometry. The upshot really is, if you want to > trivially predict what pixels will be hit for stroking, put your > geometry on 1/2 pixel boundaries. Then when I outset by 1/2 the > strokeWidth, the center-line pixel will always get hit. > > mike > > On Sep 11, 2008, at 9:12 AM, sahn0 wrote: > > Yes, p is Paint object set up as follows: > > Paint p=new Paint(); > p.setColor(0xFF80); > p.setStyle(Paint.Style.STROKE); > > Style.STROKE is needed for drawRect to actually draw rect, issue with > right-bottom pixel shows itself independently of Style. > > On 11 сент, 19:48, Mike Reed <[EMAIL PROTECTED]> wrote: > > > Might be a bug. Can you put a more complete code snippet (including > > how the paint (p) was setup) into the bug? > > > thanks, > > mike --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: drawLine is broken
Yes, p is Paint object set up as follows: Paint p=new Paint(); p.setColor(0xFF80); p.setStyle(Paint.Style.STROKE); Style.STROKE is needed for drawRect to actually draw rect, issue with right-bottom pixel shows itself independently of Style. On 11 сент, 19:48, Mike Reed <[EMAIL PROTECTED]> wrote: > Might be a bug. Can you put a more complete code snippet (including > how the paint (p) was setup) into the bug? > > thanks, > mike --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] How float coordinates are mapped to pixels (rounded)?
How exactly float coordinates are mapped to pixels (provided that there is no transformation)? I guess they are rounded in a good old fashion way: (int) (floatCoordiate+0.5f). Am I correct? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] drawLine is broken
Consider two ways to draw a rectangle:
//-
int x=10;
int y=10;
int w=2;
int h=2;
canvas.drawRect(x,y,x+w,y+h,p); // (1)
float[] lines=new float[]{
x,y,x+w,y,
x+w,y,x+w,y+h,
x+w,y+h,x,y+h,
x,y+h,x,y
};
canvas.drawLines(lines,p); // (2)
//-
You may think that they both produce same rectagle, but you would be
wrong.
Call (2) draws a rectangle without bottom-right pixel. (Call (1) draws
rectangle correctly.)
This is because drawLine doesn't draw endpoint's pixel. So
drawLine(0,0,2,0) draws 2 pixels, not three. Hence the missing pixel
at the bottom-right (drawLines also sorts points, so bottom line is
drawn from (x,y+h) to (x+w,y+h)).
This behaviour is different from J2ME's & J2SE's, where drawLine
always draws both endpoints, and drawing rectange with drawLine
produces same result as drawRect.
The question is: is this a bug?
--~--~-~--~~~---~--~~
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
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Scaling 9-patch drawable *down*
Well, you can scale down and preserve corners at the same time. Just copy four image corner parts of (width/2 x height/2) size each. This of course is not an ideal solution, but it will work for most drawables & most sane sizes (will work for my case too). Just a proposition. I checked out help and it seems that in my case I drew into size which was smaller than drawable's minimal size. On 10 сент, 00:20, "Romain Guy" <[EMAIL PROTECTED]> wrote: > It is normal. > > The whole point of a 9-patch is to preserve the corners. It is > therefore not really possible to scale them down correctly. > > On Tue, Sep 9, 2008 at 10:15 AM, sahn0 <[EMAIL PROTECTED]> wrote: > > > It seems that nine-patch behaves wierdly when scaled down. > > I created button and specified it to be 20x20 pixels. Button drawable > > is 44x48 and has 2x2 stretchable area. Downscaling produced weird > > results. In fact, the result didn't seem to be the result of scaling > > at all. It looked like result of overlapping copy operations, which > > were restricted to 20x20 clip. > > > The question is: is this normal? Or is it a bug? How in theory 9- > > patches should/can be scaled down? > > -- > Romain Guywww.curious-creature.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Scaling 9-patch drawable *down*
It seems that nine-patch behaves wierdly when scaled down. I created button and specified it to be 20x20 pixels. Button drawable is 44x48 and has 2x2 stretchable area. Downscaling produced weird results. In fact, the result didn't seem to be the result of scaling at all. It looked like result of overlapping copy operations, which were restricted to 20x20 clip. The question is: is this normal? Or is it a bug? How in theory 9- patches should/can be scaled down? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Can't specify resources for different dpi
It seems that in 0.9 SDK it is impossible to specify drawables (and other resources) for different pixel density. With image.png both in drawable and drawable-96dpi I get "ERROR Resource entry image is already defined.". Is this a known bug? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: About dexdump for beta0.9
For parsing 0.9 xml files you can use AXMLPrinter from http://code.google.com/p/android4me/downloads/list. On 26 авг, 10:53, Hiro <[EMAIL PROTECTED]> wrote: > In old version, android supplied a tool named dexdump for developer. > But it can't handle the newest dex file. Why had it been removed from > new version? And when can we get the new version dexdump ? And the new > xml file had been changed too. When can we get the new axml2xml.pl > tools for parsing 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 [EMAIL PROTECTED] Announcing the new Android 0.9 SDK beta! http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
