[DEV IDEA] Fixing Android 2.3 SDK Build Lag - OpenGL to blame? - HD2 Android Q&A, Help & Troubleshooting and Genera

Just thought of something.
Since we have all the working 2.2 builds that use the right drivers, I'm pretty sure the Android 2.3 gingerbread "lag" is not the SDK build itself - I think it's the OpenGL files (that run SurfaceFlinger/UI?) that are set in "framebuffer" emulation mode (due to the ROM being intended for use in the SDK Emulator), which is using the GUI to render all the elements, not the GPU Hardware. In theory, if we used the 2.2 OpenGL Libraries, we should have better performance as they'd be using the GPU hardware.
Sidenote: the HD2 actually has a AMD/ATI chip in it, consider it as a Pocket Radeon Graphics Chip if you like (when the graphics hardware is initialzing, you'll see an reference to AMD OpenGL).
Don't take me word for word on that, but the idea I got is someone (maybe m-deejay or whoever) should try to take the OpenGL libraries from a working Android 2.2 ROM, and paste them into an Android 2.3 ROM (either mine or m-deejays, you decide). Of course, make a backup before hand, so if Android doesn't work after that, we can rollback to the 2.3 drivers. They should be libopengl or libegl or something else, I can't remember 100%.
Happy hacking peeps! Let's get Android 2.3 running butter-smooth on our HD2!

Im gonna take a look at it after I get back home from the hospital.
Sent from my Decepticon using XDA App

spbeeking said:
after I get back home from the hospital.
Click to expand...
Click to collapse
get well soon.... or the person who is in there
@iced
pretty nice theory..... i also wondered how it can be that its so laggy, when every driver is available

Nope, the lag is caused by the vm heap in build.prop (raise it to 32) and the excessive amount of resources inside apks (every apk loaded fills up the memory in no time). Remove all mdpi and ldpi folders from all apks (even framework-res) and that should speed things up considerably.
I do this for the Dream everytime a new SDK is released and a quick-and-dirty port ensues

jubeh said:
Nope, the lag is caused by the vm heap in build.prop (raise it to 32) and the excessive amount of resources inside apks (every apk loaded fills up the memory in no time). Remove all mdpi and ldpi folders from all apks (even framework-res) and that should speed things up considerably.
I do this for the Dream everytime a new SDK is released and a quick-and-dirty port ensues
Click to expand...
Click to collapse
Thanks for that info, I'll go and do that.
Our HD2 is a HDPI device, no?

IcedCube said:
Our HD2 is a HDPI device, no?
Click to expand...
Click to collapse
Yes. it is

No worries. I did what jubeh said, and I noticed a boost in performance. You're getting a shoutout in my credits list.

Related

JIT on galaxy s

Recently, I finished finally modifying the xperia x10 that I have and one of the greatest improvements that those guys achieved was getting a lot more processing power by enabling JIT.
So naturally after seeing it work miracles on the x10, I went to look for it on my captivate and so far have come up with nothing anywhere. I saw some discussion in the past about it but nothing beyond.
Hopefully somebody can enlighten and if such a thing does seriously want to be worked on.... Here's a thread!
Sent from my GT-I9000 using Tapatalk
FroYo (2.2) and later have Just-In-Time compilation (JIT) out of the box. There are probably a dozen FroYo ROMs on the front page alone, so pick one have fun!
From what I've read, it's been a part of the ROMs since 2.1 but it needs to be enabled. Is this the case here or am I missing something?
Sent from my GT-I9000 using Tapatalk
kr3w1337 said:
From what I've read, it's been a part of the ROMs since 2.1 but it needs to be enabled. Is this the case here or am I missing something?
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
That is one of the biggest parts of froyo is that it enables JIT...so if you run a rom that has froyo its enabled unless I'm mistaken...
Sent from my GT-I9000 using XDA App
JIT is enabled by default in all Froyo ROM's. You can check the build.prop for ****s and giggles though.
The Galaxy S won't show the kinds of scores that Qualcomm based devices will, even with JIT enabled. Qualcomm included 128-bit SIMD Floating Point extensions with Snapdragon, while the Hummingbird only has 64-bit extensions.
yes with jit we get a 60-70% improvement but a qualcom gets 300%+ in floating point operation. in modern computers there are many other factors though and quardrant cpu scores are still very high for our chip (if you use the pay version you can see the score breakdown). so dont let the linpack scores discorage you. ive gotten as high as 18.2 in linpack with some overclocking though, which isn't bad. it's not the 50+ in the qualcom phones with some mods but not bad.
So that's what the story is, thanks guys! Wondering if things could be improved beyond overclocking...
I know it can be but don't know how. Some guys are getting 25+ in linpack on there website. So there is something else holding us back a bit.
Sent from my SAMSUNG-SGH-I897 using Tapatalk
Dani897 said:
I know it can be but don't know how. Some guys are getting 25+ in linpack on there website. So there is something else holding us back a bit.
Sent from my SAMSUNG-SGH-I897 using Tapatalk
Click to expand...
Click to collapse
You talking about xperia x10? really 25 on linpack? I dunno if that is even possible to OC to astronomical speeds. They run on older hardware and I think most are still on 2.1.....
All Android ROMs have a JIT compiler, it literally is what compiles all the Java on the fly. Newer versions are optimized for better performance.
So the better question is do the 2.2 Froyo ROMs have the latest JIT compiler version available or does the Nexus S have a newer more performant version we can steal. More than likely it will not work with 2.2 since the Nexus S is using 2.3.
From everything I have heard the newer JIT comp versions are optimized for the Snapdragon chipset more than anything. Which doesn't do us much good.
2.2+ have the JIT. Prior to 2.2, all programs ran entirely as interpreted bytecode on an isolated virtual machine. In 2.2+, the JIT translates the most cpu "heavy" bytecode down to native instructions during execution, stores it in cache, then runs it natively on the processor in a protected mode. Dig the video below, it's an hour long but the functionality of the JIT is explained in the first 15 minutes.
^Edited the above to accurately describe the function of the JIT
http://www.youtube.com/watch?v=Ls0tM-c4Vfo There you go, dudes. JIT Demystified.
modest_mandroid said:
2.2+ have the JIT. Prior to 2.2, all programs ran as bytecode on an isolated virtual machine. In 2.2+, the JIT translates the bytecode down to native instructions just before execution, then runs it natively on the processor in a protected mode. Could be wrong, but to my understanding, that is the major difference between 2.1- and 2.2+.
http://www.youtube.com/watch?v=Ls0tM-c4Vfo There you go, dudes. JIT Demystified.
Click to expand...
Click to collapse
This is what I saw and know too. However, I believe that the compiler that we are using is rather old and has some room for improvement. The nexus S compiler working on the captivate is a possibility that could become true after the 2.3 port is finished, provided that the developers look into it.
Sent from my GT-I9000 using Tapatalk

[Q] How are apps using dual core in the new android phones?

I already posted this in general, but this might be a more suitable place.
The way I see it, android (especially the newer versions) are capable of distributing several processes over the dual cores. Apps however don't utilise both cores.
Another question: what kind of apps would benefit from using both cores? I could imagine that heavy games and home launchers could benefit from using both cores.
Are there tools available for android that enable multithreading apps? And what are the average prices of app development tools?
Im currently working in Java, but how do most people write Android apps?
Just found some information that confirms my thoughts on how android uses parallel structures, but this still leaves open my other questions:
"Android 2.2 already takes advantage of multicore. Anything that multitasks and multithreads already takes advantage of multicore. But this exploitation is a matter of degrees.
Android 2.3 takes further advantage of the multicore, because unlike Android 2.2, 2.3's file system is multithreaded one, not single threaded. When it comes to file I/O or database searches. 2.3 will be a lot faster.
Android 2.4 or 3.1 as rumored to be, will take even greater advantage of multicores with further "architecting" parts of the OS to use more multithreads."
Android 2.3 has concurrent garbage collection which I imagine will take advantage of dual core phones. This should really help to reduce any lag or stuttering in apps and games.
First, if you develop something that requires much CPU power, then you should always try to do it using multiple threads. This is a general rule, not only related to Android.
Second, main thread of an app is UI thread and you should never run CPU-consuming tasks in it. So actually you are forced to use multi-threading in Android apps.
Third, there are many things that Android itself could run in parallel to your app: garbage collector, UI changes, animations, background apps, etc.
Brut.all said:
First, if you develop something that requires much CPU power, then you should always try to do it using multiple threads. This is a general rule, not only related to Android.
Second, main thread of an app is UI thread and you should never run CPU-consuming tasks in it. So actually you are forced to use multi-threading in Android apps.
Third, there are many things that Android itself could run in parallel to your app: garbage collector, UI changes, animations, background apps, etc.
Click to expand...
Click to collapse
Thanks for you quick answer! Could I use a Java solution that makes multithreading obsolete to make this all easier? And then just pack it into an apk? Sorry, but im pretty new to this.
Stitch! said:
Thanks for you quick answer! Could I use a Java solution that makes multithreading obsolete to make this all easier? And then just pack it into an apk? Sorry, but im pretty new to this.
Click to expand...
Click to collapse
I don't understand. How does Java makes multithreading obsolete? Besides, MT isn't really that hard if you have good tools for asynchronous processing of tasks. Java/Android gives you such tools.
Brut.all said:
I don't understand. How does Java makes multithreading obsolete? Besides, MT isn't really that hard if you have good tools for asynchronous processing of tasks. Java/Android gives you such tools.
Click to expand...
Click to collapse
Not Java, but an Java extension called Ateji Parallel extensions. There is a demo here: http://www.youtube.com/watch?v=8MDbqTgCDIA
I was just wondering, if it would be worth developing for android. The video is a demo on a dual core, and the new quadcore dev kit just came in. Additions to the that I thought about now are a timer and perhaps some other figures that can indicate the difference. Do you have any ideas on this?
Really appreciate you input, thanks!
Stitch! said:
Not Java, but an Java extension called Ateji Parallel extensions. There is a demo here: http://www.youtube.com/watch?v=8MDbqTgCDIA
I was just wondering, if it would be worth developing for android. The video is a demo on a dual core, and the new quadcore dev kit just came in. Additions to the that I thought about now are a timer and perhaps some other figures that can indicate the difference. Do you have any ideas on this?
Really appreciate you input, thanks!
Click to expand...
Click to collapse
Yes it would be worth it to develop for android. The newer android phone's dual core processors are utilized by games but only when a new version of android (future ice cream sandwich and later so i have read), will be able to support multiple processors. Also android really needs some 3D HD games like what Apple has made for the Iphone. I hope you decide to develop for android.
I still don't understand why it's so important to you. You don't need Ateji to utilize multiple cores, actually their demo is just a few lines of pure Java code. Ateji could make things easier, but it doesn't do any magic.
Stitch! said:
Another question: what kind of apps would benefit from using both cores? I could imagine that heavy games and home launchers could benefit from using both cores.
Click to expand...
Click to collapse
Anything involving image processing is a good candidate. For example, if you want to sharpen a photo, you can have one core processing the top half and one core processing the bottom half. Saying that though, I've found the single threaded performance of newer processors is fast enough for typical image filters.

420MB Huge RAM Kernel from China

*Disclaimer*
This is not my work and I am just posting it here in case some of you are interested. I take no responsibility for any problems on your phone. Don't expect any support from me.
**NOT TESTED BY MYSELF**
This kernel is for ICS, made in China.
Basically a 420MB RAM is the only difference from other kernel (although it's a big one).
Not working:
-Video recording
-HW decoding
-Camera FC when changing resolution (seems to be a problem on every ICS ROM)
Working:
Everything else
Original thread:
http://bbs.lidroid.com/forum.php?mod=viewthread&tid=102046
Downloads: http://code.google.com/p/all-roms/downloads/list
The original thread says that the developer tested it with CM9 and AOKP builds.
Have fun!!
Sent from my GT-I9000 using XDA
OMFG this kernel is AWESOME!!
Working great here!
EDIT:
Gameloft games don't work couse they use a HW decoded Gameloft logo movie at the beginning so the phone restarts.
What about building a new kernel like this one but... In english ?
My assumption that this would be:
The ramdisk or whatever it called has been modified, i have heard this before with my Nexus S, its so called : BIGMEM...
Sent from my Nexus S using Tapatalk 2 Beta-4
Is this based on platypus? Or did he only took the updater-script of it?
This should be placed in SGS development!
I won't post it in development as I didn't do any. (And I don't know how to!)
Just hoping that some devs see it and get interested?
Sent from my GT-I9000 using XDA
Not a lot of people come here... Hope they notice it? lol
nice
tried on Dark knight.
work very well. but camcorder fc.
interesting
Isn't part of the RAM required by the gpu? Maybe that's why it has hardware decoding issues??
We normally get 340Mb Ram with bigmem kernel (break HD record), he disable the MFC in http://pastebin.com/f5ytsipx so the kernel reclaim 70Mb from video HW decoding, so the kernel got 420Mb, but it's not the way to do things, probally will never get into out mainline kernel
Uuh, if there only was a way to keep HW decoding AND get 420 mb! My SGS sure could use extra 70mb, 330 is just NOT ENOUGH for Android.
Wow, I would love to try it if it were a gingerbread (stock) kernel .
If people want to use multiple kernels, it probably only takes a minute to flash an alternate kernel and reboot your device. that way you get the best of both worlds (but admittedly it is not the best solution).
I just went and read about the thread since I can read chinese lol
The dev there said he based his kernel on this guy https://github.com/ngiordano/ics_3.1.10
and Funnnny was correct, he disabled the MFC so that android can reclaim the reserved ram from that unit, which is about 70MB. But this breaks hardware video decoding and camcorder.....
But he made a compensation in the recovery so that when you need camcorder you can reboot and flash standard kernel, when you don't need it, you can flash back to the huge ram kernel....
dunno if that's useful....
Oh but can't play any games. Giving fc. I'm very interested! If you can override videos in game, you can play. Lets find a way to fix it. Think think rhink
Sent from my GT-I9000 using Tapatalk 2 Beta-4
Very interesting! How long have users complained "Where is our 512mb???" etc etc lol.
Is it just me or does dedicated RAM seem not necessary? Maybe it is possible to remap video/gpu/camera or whatever to shared RAM?
+1 oswade.
btw,which one to download??:there's one named i9000 and another t959 kernel panic fixed.
edit:well I downloaded the i9000 one. .it feels good to see 240 mb free ram on the info screen.
hope some developer further develops this idea.
oswade said:
Very interesting! How long have users complained "Where is our 512mb???" etc etc lol.
Is it just me or does dedicated RAM seem not necessary? Maybe it is possible to remap video/gpu/camera or whatever to shared RAM?
Click to expand...
Click to collapse
Dedicated RAM isn't necessary of course, but the Exynos SoC have MFC module that expect to use the Ram at a specific address, so the kernel can't touch it (known as reservation).
We can't just take the reserved Ram and use it, because next time when the module need it, it'll only use the Ram at the address it knows, and bang, the phone rebooted like the kernel in OP.
This is not just bad design at software level, maybe bad hardware design too, but I'm not system expert so I can't say anything here, but Exynos is a cool SoC and we should live on with this.
burakgon said:
Oh but can't play any games. Giving fc.
Click to expand...
Click to collapse
I've tried:
Dead Space
Andry Birds
Reckless Getaway
Hot Springs Story
They does work.
SPY mouse restarts the phone. I guess, it has a video in it.
Anyway, this kernel is rather interesting. I do hope that devs would find a way to trick SGS to play HD videos in software mode to avoid reboots. This way we'll have 70mb extra ram and won't lose anything - even if those videos would lag - who cares?
Also tried this kernel on ics slim and it feels good to have such ammount of free ram.
I also run dead space and reckless racing without any problems.Im assuming gameloft games wont run because they have always a video introducing the game.I just wish someone could break the video aceleration even if we had to loose lets say 20 mb of ram.Still would be very usefull.Ive posted in the stratosk kernel thread about this to see if he is interested on modify this kernel and make it even better

Linaro - 30% to 100% more performant Android system

Some guys found a huge optimization for Linux kernel and Dalvik as well on ARM platforms. Actually it is not made by optimizing the code, but by the way GCC compiles, and it increased the performances from 30% to 100%. There is a little video of them running a benchmark on two Android development platforms, the two development platforms are the same. Here it is :
So the ROM used is the same used by the Galaxy Nexus, and Cyanogen Mod now uses it to gain these 30%~100%. What are your feelings about it ? Are you pessimistic, optimistic about the implementation for example for stock Atrix ROMs ? Or community ROMs maybe ? Also tell us if you have some news about it.
So this optimization was made mainly for the Linux kernel on ARM devices, which means it will be way more efficient on ARM computers/servers. This is a great step forward for Linux on embedded platforms. They also worked on Dalvik, so now even Android apps will run faster.
(Sorry for my grammar if I made some mistakes, just tell me I'll correct them.)
Very impressive performance increase. Looking forward to seeing these optimizations make there way into custom roms.
Can you post more info about how this works? Or a link to the original GCC discovery?
Linaro is a hot topic in the Samsung forums. Even the OG SGS (basically half the specs of the Atrix) users are begging support for it...
Sent from my MB860 using XDA Premium App
It will be implemented in the aokp #39 release.
Inviato dal mio Atrix con Tapatalk
AkaGrey said:
It will be implemented in the aokp #39 release.
Inviato dal mio Atrix con Tapatalk
Click to expand...
Click to collapse
how do you know that???
facuxt said:
how do you know that???
Click to expand...
Click to collapse
http://www.droid-life.com/2012/06/1...stem-performance-boosts-are-quite-noticeable/
Sent from my MB860 CM7.2 RC3 36p Radio
It seems it is not easy to get this to work on every CM device. Some people report issues with this patch: http://r.cyanogenmod.com/#/c/17535/
v.k said:
It seems it is not easy to get this to work on every CM device. Some people report issues with this patch: http://r.cyanogenmod.com/#/c/17535/
Click to expand...
Click to collapse
It may not be easy, but I got a feeling that many people from CM teams everywhere are gonna work round the clock to get this to work on their devices.
I'm definitely not a "benchmark guy", and generally shrug off those topics, but even I was blown away after watching this video...
Sent from my MB860 using XDA Premium App
Wow. Awesome!
Imagine that guy talking one on one with a girl though......
Sent from my MB860 using XDA
rancur3p1c said:
Can you post more info about how this works? Or a link to the original GCC discovery?
Click to expand...
Click to collapse
Well all is about the compilation, they didn't change the code but the way GCC compiles it, it is now optimized for the ARM instruction set. So, why wasn't it optimized before the "discover" ? Well I think they didn't take enough time on build optimization when they made GCC working with ARM. First it was made for x86, x64 etc. These are other instruction set, another list of commands the CPU is able to work with. Imagine the instruction sets like different languages. x64, the first one, has a rich vocabulary, and ARM the second one has a more restricted vocabulary but the two languages have the same syntax. The difference will be that you will need to use more words with ARM than with x64 to describe something complex, so now it has to be optimized to use the fewer words possible to be faster. And that's basically what the Linaro Team did.
So the optimization has been used for the Android System (Linux kernel + Dalvik, etc.) but it can also be used for any other ARM program. This is a great step forward also for ARM computers, and maybe ARM servers that will continue to use less energy for bigger tasks because of the optimization.
Slymayer said:
Well all is about the compilation, they didn't change the code but the way GCC compiles it, it is now optimized for the ARM instruction set. So, why wasn't it optimized before the "discover" ? Well I think they didn't take enough time on build optimization when they made GCC working with ARM. First it was made for x86, x64 etc. These are other instruction set, another list of commands the CPU is able to work with. Imagine the instruction sets like different languages. x64, the first one, has a rich vocabulary, and ARM the second one has a more restricted vocabulary but the two languages have the same syntax. The difference will be that you will need to use more words with ARM than with x64 to describe something complex, so now it has to be optimized to use the fewer words possible to be faster. And that's basically what the Linaro Team did.
So the optimization has been used for the Android System (Linux kernel + Dalvik, etc.) but it can also be used for any other ARM program. This is a great step forward also for ARM computers, and maybe ARM servers that will continue to use less energy for bigger tasks because of the optimization.
Click to expand...
Click to collapse
You lost me at compilation...lol
Sent from my MB860 using XDA
So they found a way to optimize compilation for arm architecture yielding massive performance boosts over current standards.. do want =D
These dudes rock.
Sent from my MB860 using XDA
michaelatrix said:
You lost me at compilation...lol
Sent from my MB860 using XDA
Click to expand...
Click to collapse
They found a way to talk to the system by saying less. Like if I would say to you, " hello, how are things in your life" but now I say, "how's things" and you understand both phrases mean the same thing. You get to the conclusion faster because you process less information but reached the same outcome. It takes less processing for the shorter phrase and improves overall response time.
Sent from my MB860 using xda premium
i don't think it'll be easy to use it for our beloved atrix, the linaro code uses a 3.2 kernel, and we're still stuck on the crappy froyo 2.6.32 kernel =/

[MOD]Disable CPU rendering/Full GPU rendering/Improve the performance of your GPU

Introduction:
The UI of android keeps improving as updates from the android team keep flowing in. There has been a massive improvement in the aesthetics and looks of the system UI from the ancient Eclair till Jelly Bean. With improving UI and better graphics the system keeps becoming an resource hog. All android smartphones these days come with a separate GPU to satisfy the graphics rendering needs of the apps these days. However the GPU doesn’t exactly help in rendering of the system UI that means the load falls of the CPU to render the system UI and other system framework.
so here is a Mod that will disable CPU rendering and enable full GPU rendering,which will let you enjoy the true power of your adreno200!
Improvements:
-Improved performance.
-Blazing speed.
-Better sound quality.
-Improved responsiveness.
-Smoother UI experience.
-Some apps(bloatware) that earlier ran slow like Facebook will turn snappy.
-Free up CPU for other tasks.
requirements:
-Rooted device
-CWM installed 4 or 5!
How to install:
1-Download the file.
2-boot to recovery mod.
3-Make a nandroid backup just in case.
4-install zip from sdcard.
5-choose Zip from sdcard and choose the file.
6-Reboot your device!
Credit:
-leolawliet
-devilpera64
reserved 1
reserved 2
of course
Thibaultblizz said:
Does this mod can operate without conflict with Fly-On Mod?
Click to expand...
Click to collapse
Yes,and I'm going to include it in the next release of Fly-On!
slaid480 said:
Yes,and I'm going to include it in the next release of Fly-On!
Click to expand...
Click to collapse
Should I install this on top of Fly-on or wait and install next version of Fly-on?
zizibuba said:
Should I install this on top of Fly-on or wait and install next version of Fly-on?
Click to expand...
Click to collapse
as you wish both method have the same effects and I recommend you to test it before the Fly-On release(I don't know which day)
Can i apply this in cm9 rc1.
shanychowdri said:
Can i apply this in cm9 rc1.
Click to expand...
Click to collapse
yes you can it's for all android versions!
Installed it on official CM7 with Fly-on mod, everything ok. When I continuously scroll through launcher, processor gets up to 800MHz 100%. Facebook does seem a little smoother.
THANKSSSS a lottt... its much smoother now.... :thumbup: love ur work
Will it work with PSN's memory mod..?
Thibaultblizz said:
Works fine on Android 4.2.2. (Jelly Bean)
The improvement is not really visible, but no problems, everything works .
Click to expand...
Click to collapse
a little improve on ICS/JB because since android 4.0 GPU is already accelerated!
saruboy said:
Will it work with PSN's memory mod..?
Click to expand...
Click to collapse
this mods have nothing to do with memory mods/scripts,this is a Egl mod,so normaly it should work!
I'm sorry I know that it doesnt have to do anything with memory it's just that I prefer to ask nowdays because better ask than regret. Thanks.
Is there a file that I can see somewhere in system and be sure that the mod is properly working?
zizibuba said:
Is there a file that I can see somewhere in system and be sure that the mod is properly working?
Click to expand...
Click to collapse
the egl.cfg (system/lib/egl/)should be 0 1 adreno200!
I'm sure the CWM flashable zip is 100% working!
saruboy said:
I'm sorry I know that it doesnt have to do anything with memory it's just that I prefer to ask nowdays because better ask than regret. Thanks.
Click to expand...
Click to collapse
ok there is no problem!
I have to admit that this mod make a phone way faster JB 4.2.2 Event facebook messanger and scrolling on the contacts list with photos on facebook synced are finnaly smooth. But have to ask how does it occur to the battery condition ? Does it make it less?
Czepek said:
I have to admit that this mod make a phone way faster JB 4.2.2 Event facebook messanger and scrolling on the contacts list with photos on facebook synced are finnaly smooth. But have to ask how does it occur to the battery condition ? Does it make it less?
Click to expand...
Click to collapse
No you will have the same battery life as before you installed this mod!
Sent from my GT-I9000 using xda premium
Delete
Enviado desde mi Nexus 4 usando Tapatalk 2

Categories

Resources