Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Android Lag, Even With Project Butter?
- Thread starter ReanimationN
- Start date
- Sort by reaction score
Try a browser other than chrome. Chrome for android in my opinion isn't ready yet. The stock aosp browser is way smoother but that's not on the stock ROM of the nexus 7 for some dumb reason. Dolphin HD or boat browser are great alternatives if you don't wanna root. Custom ROMs have the aosp browser and you can install it on the stock ROM as well with root.
----------
Having used ICS and jb extensively on my galaxy nexus its not using raw power. Jb is much smoother and no longer has the lag whenever a toast notification would come up. It also doesn't lag because of the button glow animation anymore. Jellybean made a huge difference for the galaxy nexus. The issue people are having with chrome is a problem with chrome. I really think Google made a mistake by only including chrome on the nexus 7. The stock android browser is so much better, faster, and smoother.
----------
Having used ICS and jb extensively on my galaxy nexus its not using raw power. Jb is much smoother and no longer has the lag whenever a toast notification would come up. It also doesn't lag because of the button glow animation anymore. Jellybean made a huge difference for the galaxy nexus. The issue people are having with chrome is a problem with chrome. I really think Google made a mistake by only including chrome on the nexus 7. The stock android browser is so much better, faster, and smoother.
Sorry, the added triple buffering, vsync pulse etc to force the OS to be smoother. Read above link.
That's the opposite Apples approach of doing less in the background. Android still does what it dud before plus some to make the OS more fluid.
Some apps for Android are just badly coded.
Take Tapatalk as a perfect example. It's buttery smooth in iOS, but in Android it stutters and freezes while scrolling even in Jelly Bean.
Enabling force gpu rendering in dev options helps a lot. There's still a bit of stutter though. That's one of the choppiest apps around. Most are much better.
Wow, you are definitely right there. I just tried Boat Browser, it's so much smoother than Chrome. The juddering at slower scrolling speeds still exists, but it's not as bad as Chrome.
That Project Butter article didn't talk about using more raw power.
VSync and sometimes using a triple-buffer, is about using better TIMING to start doing the same things it did before.
The juttering is nexus 7 specific. Theres actually newer touchscreen drivers out now that fix it, they should be included in the next OTA update. Custom roms have already solved this but google just pushed the new drivers to AOSP which means they will be included in the OTA.
You can read more about the new drivers here.
http://forum.xda-developers.com/showthread.php?t=1905961
Now that is good to hear! I feel a lot less hesitant about an S3 now.
Excellent, can't wait for the update. Generally how long does an update take to get pushed out to stock Nexus devices after Google's released new code?
I guess we are defining raw power differently. Using "things" and doing more is what I mean. The opposite approach would be doing less in the background to allocate resources for fluidity.
I don't mean it's using more energy or you need to shovel coal into the phone or whatever you are assuming.
Whenever the OTA is issued you should get it instantly. Google should be doing an OTA pretty soon most likely.
Carriers hold up the process, this is why GSM models get updates before Verizon. If its a wifi device like the Xoom or N7. You get the update immediately but if the device has cellular data it has to be tested by the carrier. Hence why the wifi Xoom has official JB but the lte Xoom does not.
Verizon Gnex is just getting JB.
On jellybean on nexus devices its definitely smoother. I can't speak for the galaxy s3 since samsung made customizations to the stock browser.
Actually, what makes iOS so smooth is that the UI has processor priority over everything else. Android takes the opposite approach, giving priority to apps above everything else.
It's weird that in actual usage Android is a goodly bit faster than iOS in certain situations, but the lag and stutters you see make you believe it's much chunkier and rough than it actually is. It's a weird situation where the presentation of smoothness and the illusion of speed gives you a better experience than honest to god actual speed.
Also, I'm fairly sure triple buffering and vsync are used in iOS. Without vsync, you'd get tearing across the middle of the screen whenever you do a quick scroll.
Last edited:
Are you serious? I have more iPhone apps not launching at all on my 4s than I have ever had on my Nexus.
I try launching Angry Birds Space, I get a black screen and then it jumps back to springboard. What's up with that? Same with GTA3.
Yep, this has long been a tug-of-war in OS design.
In the earliest days of personal computers, the OS needed priority in order to handle a lot of time-dependent tasks (software serial ports, keyboard scanning, etc). Later, as chips were made to take over such tasks, the OS could afford to let UI actions take more precedence.
My own background is heavily in realtime systems, where UI actions had to take less precedence at times. For example, it is almost always more important to close a valve to prevent the factory from blowing up, before showing the user that the valve has closed
Btw, another way that iOS differs (or rather, differed) is that it tended to show a lot of blank screen if it couldn't keep up. Android tended to wait until the data was ready to show before continuing. This caused list scrolling lag on Android while it waited for good data to be drawn, versus fast scrolling on iOS that had missing data.
Yes, the technique of at least double-buffering and flipping buffers during vsync, has been used since the dawn of computer graphics.
What they're talking about here, is simply making sure that drawing on Buffer B for the next screen STARTS the earliest that it can (right after Buffer B is no longer being displayed), instead of just randomly starting at some other point in time.
The point is that it's neither doing more nor less.
It's doing the same old stuff, but starting at an earlier point in order to lower the chances of the drawing not being ready to be displayed at the next usual frame time.
The only resource it uses more of, is sometimes a third screen buffer.
Cheers!
I can assure you I'm not trying to start a debate over what it is or isn't doing but if you feel the need to be right you'll contradict yourself I'll gladly concede the conversation. It does precisely what you say it does, which is exactly what I said....
And the fact that iOS was actually designed to provide a multitouch experience from day one. As was Windows Phone.
They weren't ripped out of a blackberry clone and shoehorned into an iPhone clone.
My only issue with the stock AOSP browser is that it doesn't sync bookmarks with my gmail account. I try to sync it in accounts but it fails every time.