Database Users

[REF] All ICS ROMs Benchmarked

Results in Google Docs Spreadsheet
All ICS ROMs Benchmarked
Any regular visitors to this thread can't have failed to notice the big changes in the spreadsheet. In particular I've been studying the effect of the kernel the ROM developer includes. If you look at column H, you will see whether I recommend flashing another kernel to improve performance at stock speeds.
REMEMBER: Performance is not everything! Many custom kernels provide extra features!
If you do decide to switch kernels, and only desire stock speeds and a reduced feature set, I recommend two kernels in this post.
If you are new to this stuff read this.
SUMMARY OF RESULTS
#1st place: Pixel ROM 1.72
#2nd place: CyberGR-MOD|NS.NGN ICS v10 HYBRID
#3rd place: MIUI Catalyst 2.4.6
#4th place: AOSP+ N.5
#5th place: [MIUI][2.4.6] Oodie pRiMe rOcket fUeled
Where do I find all these wonderful ROMs?
Their XDA threads are all linked in the table, so click through to discover each ROM's feature set, included apps, theme, and evidence of good karma!
Looking for a Gingerbread ROM? Try this.
Where did all your other benchmarks go?
Kernel Features & Benchmarks: this thread
Battery drain: this thread
CPU Governors and I/O Schedulers: this thread
Power Saving Governors: this thread
Thanks to all the developers.

Testing Methodology
Each ROM is clean installed, allowed its own default settings, then all benchmark software is installed and run once the system is settled. I also perform one screen off screen on, just out of habbit (this used to resolve a graphics bug in gingerbread, which I'm not even sure exists in ICS). All results are recorded in the spreadsheet. Then I restart in recovery, wipe cache and dalvic (thanks morfic for dalvic wiper) and install morfic's T132-I kernel. Reboot, use nstools to select performance (default I/O scheduler for morfic's kernel is deadline). Reperform all benchmarks, recording them in the spreadsheet. The calculation for the overall CPU RAM I/O and GRAPHICS scores is identical to the one I use in my kernel benchmarking spreadsheet. Please refer to that thread for more detail. However, there is one difference. Quadrant behaves very differently in different ROMs depending on what graphics tweaks they incorporate. As such, no Quadrant scores are used in this ROM benchmarking study. For more details, see under 'Graphics' below.
The final step was to average out the results of both kernel scores, and ranking on that basis. Some would say that they are best ranked by looking at T132 scores only. I would say that is a fair point, and definitely worth consideration.
There are two reasons I incorporate the default kernel score:
1) Overall scores have a worst case scenario accuracy of within 2% of the true mean due to variability in the benchmarks (more detail on how I obtain this figure is available in my kernel benchmarking thread). For normally distributed data (which we can safely assume these benchmarks produce) averaging two sets of results will result in doubling the accuracy to within 1% of the true mean, making the ranking more reliable.
2) Combining the default kernel Scores for ROMs that used a poor performing kernel, or selected bad governor/scheduler combinations by default will suffer as a consequence. These problems can be solved if the user flashes their own preferred kernel and/or adjusts the kernel settings. However, many new users will not perform this step. For that reason, I want to give a score that at least somewhat reflects the performance as the developer intended.
-Graphics
One of the early findings is selecting force GPU rendering in the developer options improves 2D performance, in Quadrant only. Also, and only in Quadrant, 3D performance can be improved by deleting or moving /system/lib/egl/libGLES_android.so using root explorer or equivalent. These tweaks/hacks do not seem to affect other benchmarks in the slightest.
Because of the bizarre effects of these tweaks on Quadrant scores, I have removed them from the formula that calculates the overall GFX score, and this in turn impacts the overall average score. In short, it makes comparing each ROM's score fairer.
You can see evidence of how the graphics tweaks make Quadrant behave differently at the bottom of the spreadsheet, highlighted in light red. The host ROM for this particular comparison was DianXin or DX ROM for short. This is a reference to a post I make in DX ROMs thread, where I first decide that removing Quadrant is the best option: http://forum.xda-developers.com/showpost.php?p=22323688&postcount=194
-Android 4.0.1
These ROMs (at the bottom of the spreadsheet, highlighted in light red) were based on early maguro ports provided by koush. I have left them in, because although they are difficult to compare to 4.0.3 builds with the correct drivers and whatnot, they do compare to each other in one important respect: the kernel. One is stock, the other is built by eugene373 (galaxy nexus/nexus s dev.) Using eugene373's kernel, CPU, I/O, and Graphics were all raised to a high standard that is on a par, or above some of the current ROMs. This goes to show that a customised kernel can offer great benefits, even on a ported ROM.
-Android 4.0.4
As of the 5th of February, my table contains all the ICS ROMs that are listed in the XDA forums. There was only one 4.0.4 version at the time, and this was the best performing in the benchmarks. When the source code is released, I'm sure many ROMs will update. At this point they will benefit from increased RAM scores and javascript performance. If all the ROMs scores improve by the same proportion, the rankings will not be affected. I will attempt to included major releases, but I will not reperform these tests every time there is a new nightly.

Reserved 4

Reserved 3

Thanks
I was waiting for this
It might lead to troll wars though
By the way, i dont see Pete ICS rom in there, im using it.

Ibn Saeed said:
Thanks
I was waiting for this
It might lead to troll wars though
By the way, i dont see Pete ICS rom in there, im using it.
Click to expand...
Click to collapse
Thanks, and no troll wars please y'all.

Don't you think "popularity" is going a little too far? It will definitely lead to fights...all the devs are good and I don't think prominence is a good indicator of a good rom
But it's up to you
Sent from my Nexus S using XDA App

Personally, benchmarks are very misleading... Some of the most stable and well developed roms don't get the greatest scores because they weren't made with benchmarks in mind.
Sent from my Nexus S 4G using xda premium

Another great work! Thanks
Sent from my Nexus S using XDA App

mathkid95 said:
Don't you think "popularity" is going a little too far? It will definitely lead to fights...all the devs are good and I don't think prominence is a good indicator of a good rom
But it's up to you
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
just remember, popular doesnt mean better. but to get angry at the truth(whatever it might be) is just silly. its lies that you should be upset with.

Where's Peter Alfonso's ROM? Bugless Beast is a mainstream rom, second only to Cyanogenmod in scope and breadth.. The ROM thread is in the General forum, because he links to his page at Rootzwiki, but it's a more prominent ROM than many you've listed.
Please include it in the benchmarking as well.
Sent from my Nexus S using Tapatalk

http://forum.xda-developers.com/showthread.php?t=1430170
you didn't add and test this one

please add pete ics bugless beast.

Omissions fixed!
UPDATE: kwiboo's project removed, was an SDK port. So so tired now, got to sleep. Tomorrow begin again with Brainmaster's tweaked ICS

Which kernel is used to make the tests?
-----
Forget It...
"I'll be benchmarking them twice with whatever kernel they come with, and then with morfic's bare boned T132"

biotecsoul said:
Which kernel is used to make the tests?
Click to expand...
Click to collapse
Read the op.
Sent from my Nexus S 4G using xda premium

u could also add overnite battery drainage column with sync on or somethin like that, if not overnite then a period of 2 hrs idle .. how much does it drain ..

Holy **** man, what would it be if the NS comunity didnt have you??
Thumbs up!!!!
Sent from my Nexus S using xda premium

thegtfusion said:
Holy **** man, what would it be if the NS comunity didnt have you??
Thumbs up!!!!
Sent from my Nexus S using xda premium
Click to expand...
Click to collapse
Haha, that makes me feel good. Wait, Benchmarks > XDA thread > Positive XDA user feedback > Dopamine release = Addiction to benchmarking? Time to join crackflashers anonymous...

mathkid95 said:
Don't you think "popularity" is going a little too far? It will definitely lead to fights...all the devs are good and I don't think prominence is a good indicator of a good rom
But it's up to you
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
I doubt it would lead to fights between devs, well hopefully not. I can see users arguing stuff more than devs.
Benchmarks aren't that good anways.
BTW, your kernel sucks!!!!
Just kidding been running smoothly since I started using it the other day
-----------
Thanks for the ratings system. Looks nice!

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 =/

SGS GPU acceleration for UI?

Hi,
I´ve read that ICS has GPU acceleration for the UI implemented as a standard. Is there really a difference in smoothness compared to custom gb roms? I´m talking about the i9001. But it should be the same as with the i9000
Regards
Lekor

Can't tell the difference.
I'm on RemICS v1.2 with Devil Kernel 3.0.72. I set GPU from stock 200MHz to OC at 250MHz and I can't tell the difference. But the Kernel developer did say it may not work. Still experimental.

Afaik no big difference, although our GPU is powerful. Maybe stock ROM has other imorovements, so the boost isn't good to feel on ICS.

Samurai05 said:
I'm on RemICS v1.2 with Devil Kernel 3.0.72. I set GPU from stock 200MHz to OC at 250MHz and I can't tell the difference. But the Kernel developer did say it may not work. Still experimental.
Click to expand...
Click to collapse
GPU OC isn't same as GPU accelerated UI
And yes ICS should benefit from it..but can't really remember anyone GB times if there has been some speed gain..
Sent from my GT-I9000 using Tapatalk 2

Yeah it does, but i reckon that ICS is really unpolished with it.

Running slim with the latest semaphore and I can definitely say this is the slickest my phone has been, but that is just my opinion
Sent from the gutter, gazing at the stars

Lekor2k said:
Hi,
I´ve read that ICS has GPU acceleration for the UI implemented as a standard. Is there really a difference in smoothness compared to custom gb roms? I´m talking about the i9001. But it should be the same as with the i9000
Regards
Lekor
Click to expand...
Click to collapse
There are apks that use the gpu. In custom roms i saw that this is true on i9001

The stock browser in 2.3.6 uses GPU acceleration. There are other apps also, but not the OS UI.
In 4.0 custom rom it should work in the apps when you enable the option from the developer options.

No difference. Everything using 8 mb more ram with 200mhz GPU acceleration.
Sent from my GT-I9000 using XDA

burakgon said:
No difference. Everything using 8 mb more ram with 200mhz GPU acceleration.
Sent from my GT-I9000 using XDA
Click to expand...
Click to collapse
Bro, just upgraded my i9000 to ice and forced gpu acceleration.
Man even on the xda app itself I can see a marginal difference in smoothness.
Sent from my GT-I9000 using xda premium

it has an option force gpu rendering that uses 2d hardware acceleration in applications...and you have to set it manual...but dont know if it rly helps in smoothness i think it depends more on the rom then to have this gpu option

MrAndroid12 said:
Bro, just upgraded my i9000 to ice and forced gpu acceleration.
Man even on the xda app itself I can see a marginal difference in smoothness.
Sent from my GT-I9000 using xda premium
Click to expand...
Click to collapse
Because it's cyanogen. You can see it's even faster on cm7.
Sent from my GT-I9000 using xda app-developers app

I see an awful lot of people saying it offers no improvements. Personally, I think it does.
I keep my phone up to date as much as possible. When ICS was stable, I jumped right in. I haven't ran Gingerbread in a long, long time—but from what I remember, it had some lag. Android, in fact, was known for this lag. You couldn't read an iOS vs Android debate without this lag being mentioned (at least when Gingerbread was the newest). And I had tried everything: every lag fix, every tweak, every ROM, every kernel, governer, scheduler, OCing, UVing—I tried it all. But I still remember there being lag.
Now I'm in the present. I've been running ICS since it was stable and, quite frankly, I don't notice that lag. I mean, yes, my phone does still lag—if I'm doing something processor intensive in the background—but not like my memories of Gingerbread. Back then, it would lag scrolling through my list of apps; it would lag doing menial UI rendering without anything running in the background. That simply does not happen anymore. Not in my experiences. Not with ICS.
Granted, as I did in Gingbread, I do in ICS—I've applied every fix, every tweak, and every possible software combination that I could get my hands on. I've tried every ROM, every kernel, every setting imaginable. And I do this because I've been thoroughly impressed by the community here at XDA. This device of ours is over 2 years old now. But the software progression does not stop. We move forward as if the hardware was built just yesterday. And I have to tell you, our phone is keeping up—it really is. My phone is faster than a lot of my peers, even with some of them having much newer hardware. And I honestly don't feel I could have said any of this if I had stayed far behind with Gingerbread.
Everyone wants a new phone. It's newer, better, faster. But what they don't realize is that software can fulfill a majority of their wants. It is a continuous improvement, however gradual it may be. To not want to upgrade your software is like not wanting to upgrade your phone. And let's be honest, who doesn't want a new phone—one that's newer, better, and faster—without ever having to buy one.
I do. And that's why I update my phone. But maybe that's just me.

[app] gs3 multisample anti-aliasing

This is GS3 MSAA Anti-Aliasing.
SIGNIFICANTLY INCREASE THE GRAPHICS QUALITY OF YOUR ADRENO EQUIPPED GALAXY S3!!
**REQUIRES ROOT!
**REQUIRES CUSTOM KERNEL!
**CERTAIN OPTIONS MAY NOT WORK DEPENDING ON THE KERNEL YOU USE.
If you play games or just want a faster running rom, this app is for you!
Better color saturation and shading.
Higher definition look to everything on screen.
Increased sharpness and contrast.
Smoother graphics rendition.
Overall faster device with PERFORMANCE MODE on any rom.
Plain and simple the GS3 has never looked this good!
THIS APP PROVIDES THE FOLLOWING SETTINGS AND FEATURES...
-All options in this app effect everything shown on your display and are on full time regardless of what is being displayed.
-Framebuffer memory.
-Grayscale.
-Bits per pixel.
-GPU overclocking
-4x and 2x multisample anti-aliasing
-GPU performance mode
-Custom build properties designed for a smooth and solid graphical experience.
-init.d support.
-Standard video test patterns.
This app is designed to work with any GS3 with an Adreno GPU and custom kernel.
THIS APP HAS ONLY BEEN TESTED ON...
-Sprint GS3
-Verizon GS3
-AT&T GS3
-T-Mobile GS3
https://play.google.com/store/apps/details?id=baldwin.com

Bump

err which custom kernel does this work with?

mbze430 said:
err which custom kernel does this work with?
Click to expand...
Click to collapse
If the kernel isn't capable of over clocking the GPU then that option in the app won't work such as Ktoonsez. Also, the faux kernel now has 5 options for the grayscale setting and the app has only 3. I believe his kernel is the only one like that. It's hard to create an app like this when kernel developers are not keeping a standard together. These are the only 2 options that may or may not work as intended based on the kernel.
If you use Faux or Ktoonsez they obviously come with their own app and can work those general features if they provide those options. Regardless, the heart of this app such as anti-aliasing, bits per pixel, and the framebuffer settings all work on any rom or kernel as they work with the file system and not the kernel. All custom kernels give the access to those options in the file system.

Got the app from the market..
GS3 running TW 4.1.2 MF1 custom rooted with LeanKernel 3.2.1 exp..
App loads, and I allowed the build.prop to be modified.
Rebooted selected the 2X and other suggestions for 'better than stock'..
status bar had some tearing / artifacts..
went to performance vs 2x, got rid of the visual problem, but frame buffer and bit depth are 'all selected'
greyscale is natural (default)
gamma is 2.0 (not stock)
- suggestions?
Thanks for the app..

Mystique said:
GS3 running TW 4.1.2 MF1 custom rooted with LeanKernel 3.2.1 exp..
App loads, and I allowed the build.prop to be modified.
Rebooted selected the 2X and other suggestions for 'better than stock'..
status bar had some tearing / artifacts..
went to performance vs 2x, got rid of the visual problem, but frame buffer and bit depth are 'all selected'
greyscale is natural (default)
gamma is 2.0 (not stock)
- suggestions?
Thanks for the app..
Click to expand...
Click to collapse
The tearing at the top of the screen is still a mystery. Sometimes it's there and sometimes its not. Still working on a resolution.
I have never seen when all the options are lit. Can you still select anything?

this app in no more on play any links

fusioncoast said:
this app in no more on play any links
Click to expand...
Click to collapse
build.prop:
ro.hwui.text_cache_height=256
ro.hwui.fbo_cache_size=16384
ro.hwui.layer_cache_size=16384
ro.hwui.path_cache_size=16384
ro.hwui.round_rect_shape_cache_size=16384
ro.hwui.circle_shape_cache_size=16384
ro.hwui.rect_shape_cache_size=16384
ro.hwui.arc_shape_cache_size=16384
ro.hwui.oval_shape_cache_size=16384
ro.hwui.texture_cache_size=16384
ro.hwui.gradient_cache_size=16384
ro.hwui.text_drop_shadow_cache_size=16384
ro.hwui.font_renderer_cache_size=16384
ro.hwui.resource_cache_size=16384
ro.hwui.patch_cache_size=16384
ro.hwui.disable_vsync=false
ro.hwui.layer_size=1024
ro.hwui.render_layers_as_regions=1
ro.hwui.stencil_buffer_size=3.0
ro.hwui.texture_cache_flush_rate=0.9
ro.hwui.panel_bit_depth=32
ro.hwui.default_text_gamma=1.8
ro.hwui.default_text_black_gamma_threshold=255
ro.hwui.default_text_white_gamma_threshold=255
ro.hwui.disable_scissor_opt=true
debug.hwui.show_overdraw=false
debug.hwui.show_layers_updates=false
ro.hwui.text_gamma_correction=shader3
and if you are interested.. look for yamato_panel.txt
I find these build prop additions are all that I need.. you might like/want the yamato stuff..
Galaxy S3 i535 Custom TW 4.1.2

Unfortunately the app has been temporarily removed due to possible bootloop issues. It will be available when the issue is resolved. Thanks for your patience.
Sent from my SCH-I535 using Xparent Cyan Tapatalk 2

can you use a working version with nexus4

[Q]why stock and TW-based roms are having a lot gaming performance than CM and AOSP-b

Hey guys,
So I recently restored to stock rom and I spotted that the gaming performance is a lot better and faster than CM-based and AOSP-based ROMs
So I am letting you guys to tell your answer why in this thread, so reply down below to tell your answer, as it's very appreciated!
Sent from my GT-I9505 using Tapatalk

I kinda doubt that. TW roms have DVFS that reduces performance if the phone gets too hot.
The only reason why it would be better is due to better software-hardware compatibility.
I saw people mentioning that TW has better hardware acceleration. This may be due to the aforementioned better software-hardware compatibility.
If this is the case, GPE roms might also have better performance, since they were also built by Samsung, they might use the same drivers.

May be you had used cm rom on balance battery mod

irfanbd94 said:
May be you had used cm rom on balance battery mod
Click to expand...
Click to collapse
Usally in CM and CM-based ROMs,
This mode is selected by default
But did you saw a increase in gaming performance when you chose performance mode?
Sent from my GT-I9505 using Tapatalk

GDReaper said:
I kinda doubt that. TW roms have DVFS that reduces performance if the phone gets too hot.
The only reason why it would be better is due to better software-hardware compatibility.
I saw people mentioning that TW has better hardware acceleration. This may be due to the aforementioned better software-hardware compatibility.
If this is the case, GPE roms might also have better performance, since they were also built by Samsung, they might use the same drivers.
Click to expand...
Click to collapse
Wait, so you are saying that the drivers in CM are made by CM? Not Samsung?
If it was, that makes so much sense right now
Sent from my GT-I9505 using Tapatalk

vbajs said:
Wait, so you are saying that the drivers in CM are made by CM? Not Samsung?
If it was, that makes so much sense right now
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
Yes that's the whole point of CM being open source.
Though I doubt that TW will give you better performance on our device due to the standard throttling on stock roms.

vbajs said:
Usally in CM and CM-based ROMs,
This mode is selected by default
But did you saw a increase in gaming performance when you chose performance mode?
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
Yes performance mod increase gaming performance.....But i am using official TW rom always.....bucause with tw rom i got better battery life,camera,display colour/graphics.....and similar gaming performance if unnecessary system app removed.

irfanbd94 said:
Yes performance mod increase gaming performance.....But i am using official TW rom always.....bucause with tw rom i got batter battery life,camera,display colour/graphics.....and similar gaming performance if unnecessary system app removed.
Click to expand...
Click to collapse
Ok, since performance mode in settings>battery increases gaming performance,
what if that performance mode enables that stock throttling from the stock rom? And the balance mode just disables that?
Can anyone confirm?
Sent from my GT-I9505 using Tapatalk

vbajs said:
Ok, since performance mode in settings>battery increases gaming performance,
what if that performance mode enables that stock throttling from the stock rom? And the balance mode just disables that?
Can anyone confirm?
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
Performance mode, as far as I know, just changed the CPU governor to the Performance governor. I don't know if it actually does anything else. Battery mode changes the governor to conservative and balanced changes it to interactive.
As far as the drivers go, all of the are based on the source code released by Qualcomm on the Code Aurora Forums (CAF). That's the starting point. From there, OEMs take the source code and modify it accordingly. CM also builds from there, but they might not spend as much time optimizing the driver's as OEMs probably do.

GDReaper said:
Performance mode, as far as I know, just changed the CPU governor to the Performance governor. I don't know if it actually does anything else. Battery mode changes the governor to conservative and balanced changes it to interactive.
As far as the drivers go, all of the are based on the source code released by Qualcomm on the Code Aurora Forums (CAF). That's the starting point. From there, OEMs take the source code and modify it accordingly. CM also builds from there, but they might not spend as much time optimizing the driver's as OEMs probably do.
Click to expand...
Click to collapse
I think now I get what you mean because have JDCteam dropped their optimized CM13, the gaming performance is way a lot better than normal CM13
Sent from my GT-I9505 using XDA Labs