or Connect
AppleInsider › Forums › General › General Discussion › 'Project Butter' to improve responsiveness in Android 4.1 Jelly Bean
New Posts  All Forums:Forum Nav:

'Project Butter' to improve responsiveness in Android 4.1 Jelly Bean - Page 3

post #81 of 109

Since ICS is installed on few new Android phones shipping at this point, and 2.3.x seems to have become Androids "XP", it's questionable how much any of this matters. It's possible that ICS will be ignored and handset makers will simply skip to JB, or maybe adoption will always simply lag release by a year or two, that they are working on their mods to ICS now, and that phones shipping with JB are still a couple of years down the pipe.

post #82 of 109
Quote:
Originally Posted by Smallwheels View Post

Think about it. Apple doesn't design the chips in their computers nor do they manufacture chips. They design tweaks to the ARM processors and someone else does the manufacturing. Google could do the same thing Apple is doing for its computer line and be considered a manufacturer just as much as Apple.

 

Wrong, the Ax chips are not generic ARM, Apple design their custom ARM in-house with help of P.A. Semi engineer who have been acquired by Apple few years ago .  Their PWRficient technology gives Apple an edge over the competition. 

post #83 of 109

I had a Samsung Showcase I500.  The lag was horrible...   It ran Gingerbread.  I have a 2nd gen IPod touch that performed better.  Now that I have an IPhone I won't go back.
 

post #84 of 109

Love it when regulars whine about 'fandroid trolls' when this article is clearly a stinkin' heap o' troll bait.

 

Anyways, continue with your Android bashing..

post #85 of 109
Quote:
Originally Posted by redbarchetta View Post

 

Sure, just like Apple admitted Android had a better notifcation system for years.

Yeah but Apple actually improved upon it. Maybe its just this particular phone (though I doubt it), but my fiancée's phone is a Sony Ericsson Xperia and whenever she gets a call or a text or anything when she isn't near the phone it just gets logged into the status bar at the top and she can't see any information until she unlocks the phone and drags the status bar down to see what has transpired. With my iPhone, anything that happens when I'm away gets logged right there on the lock screen and is ready for me to see who I missed without even having to unlock the phone. 

 

Let's put it this way, I wouldn't say Android had a better notification system cause a bunch of random icons at the top really doesn't notify of much especially if you don't know what any of them even mean. iOS has a notification system that actually lets you know stuff happened and when with little effort.

Samsung Galaxy series: Faster on a benchmark, not in your hand.

Reply

Samsung Galaxy series: Faster on a benchmark, not in your hand.

Reply
post #86 of 109
Quote:
Originally Posted by Curmudgeon View Post

 

Whored out?    Climb down from the ledge.   You're getting dizzy.   MacOS X itself, is based on FreeBSD - an open source version of Unix/Linux.  And yet Apple has been able to make something quite nice out of it.   I won't assume that Google can't do the same.

 

Uh, no. FreeBSD is an open source "version" of "unix" but not of "linux". "unix" is in quotes as UNIX and probably Unix are trademarks and have specific requirements to claim compatibility with, and I don't think FreeBSD strives to maintain strict compatibility. FreeBSD does use some of the gnu userland and toolset, which linux also does, but FreeBSD really has nothing to do with Linux. FreeBSD is based on BSD 4.4lite, a non-encumbered version of the Berkely unix that arose an alternative to AT&T unix. OS X is not based on FreeBSD. OS X only took the userland (shell and related user environment/utilities) from FreeBSD and put it on OS X and it also added a FreeBSD compatibility layer (kernel interface) so that the userland and utilities would work on the OS X kernel. The OS X kernel has nothing to do with FreeBSD, nor does the GUI or anything else. Only minimal pieces were taken from FreeBSD. The OS X kernel is a hybrid mach 2 and mach 3 kernel heavily modified by Apple. mach original came from CMU. --
post #87 of 109
Quote:
Originally Posted by canoeberry View Post

 

My iPhone 4 is slow as thick shit. Lag is a polite word to describe what ALL my applications that used to work very well now do on a regular basis. So Apple better get their act together, unless they are just writing off YET ANOTHER  GENERATION of iPhone after less than two years on the market.

 

Which is exactly what they have been doing to the rest of their hardware as well. If you don't have an SSD in your Mac don't bother running Lion: they didn't design lion for such old fashioned storage devices.

 

Maybe your iPhone 4 has a problem then, as my wife's iPhone 4 works just fine and smooth. And you don't need a Mac with ssd to get good performance with Lion. We have it on several Macs, only one of which has an ssd (Macbook 2008 with aftermarket ssd). It works just fine. Have not noticed any problems which makes 10.6 better (which I also still have running on some machines, as well as 10.5). --
post #88 of 109
Quote:
Originally Posted by chadbag View Post

 

Uh, no.FreeBSD is an open source "version" of "unix" but not of "linux". "unix" is in quotes as UNIX and probably Unix are trademarks and have specific requirements to claim compatibility with, and I don't think FreeBSD strives to maintain strict compatibility. FreeBSD does use some of the gnu userland and toolset, which linux also does, but FreeBSD really has nothing to do with Linux. FreeBSD is based on BSD 4.4lite, a non-encumbered version of the Berkely unix that arose an alternative to AT&T unix.OS X is not based on FreeBSD. OS X only took the userland (shell and related user environment/utilities) from FreeBSD and put it on OS X and it also added a FreeBSD compatibility layer (kernel interface) so that the userland and utilities would work on the OS X kernel.The OS X kernel has nothing to do with FreeBSD, nor does the GUI or anything else. Only minimal pieces were taken from FreeBSD. The OS X kernel is a hybrid mach 2 and mach 3 kernel heavily modified by Apple. mach original came from CMU.--

 

MacOS X is a certified Unix'03 OS, OSX use FreeBSD and NetBSD for its user land which is called Darwin and is fully open source.  The UI is a 100% Apple-NeXT closed source creation of a Postscript vector based display, which is the only current UI who can drive the retina display on mobile and desktop, keeping normal resolution for unoptimized apps while boosting fonts resolution.  

post #89 of 109
Quote:
Originally Posted by canoeberry View Post

 

If you don't have an SSD in your Mac don't bother running Lion: they didn't design lion for such old fashioned storage devices.

Odd, we've got five Macs running Lion here.

 

One of them, a late-2006 20" is the only one that you might hesitate to use for photo, video or audio production, and most of the time it's ok for those uses. When it''s rendering video files, you leave it to crunch and use something else, but that was true before Lion showed up.

 

The MacBook Airs (one a late-2009, the other a late-2010) have SSDs, but other than being quicker to start up, they're not faster than the (early-2009, 24" and mid-2010, 21.5") iMacs. All of them are more than tolerable to use.

post #90 of 109
Quote:
Originally Posted by BigMac2 View Post

 

MacOS X is a certified Unix'03 OS, OSX use FreeBSD and NetBSD for its user land which is called Darwin and is fully open source.  The UI is a 100% Apple-NeXT closed source creation of a Postscript vector based display, which is the only current UI who can drive the retina display on mobile and desktop, keeping normal resolution for unoptimized apps while boosting fonts resolution.  

Sorry, OS X abandoned the Display PostScript approach that NeXT used right from the beginning in favor of their own version of PDF-based rendering. IIRC, it was initially done because they couldn't come to an agreement with Adobe on using Display PostScript, but OS X never shipped with it.

post #91 of 109
Quote:
Originally Posted by chadbag View Post

Maybe your iPhone 4 has a problem then, as my wife's iPhone 4 works just fine and smooth.And you don't need a Mac with ssd to get good performance with Lion. We have it on several Macs, only one of which has an ssd (Macbook 2008 with aftermarket ssd). It works just fine. Have not noticed any problems which makes 10.6 better (which I also still have running on some machines, as well as 10.5).--

I think the difference is in usage. Saying that one lags and the other doesn't is meaningless.

I have an iPhone 4. On normal actions, checking email, browsing, changing screens, scrolling etc, it is perfectly fluid - no sign of a lag. However, if I launch a graphics heavy app (such as Dragonvale with hundreds or thousands of graphics items to be manipulated, there is sometimes a lag.

With my daughter and ex's Android phones, OTOH, there is a lag even in moving from one screen to another or scrolling web pages. The entire UI lags.
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
"I'm way over my head when it comes to technical issues like this"
Gatorguy 5/31/13
Reply
post #92 of 109
Quote:
Originally Posted by steveH View Post

Sorry, OS X abandoned the Display PostScript approach that NeXT used right from the beginning in favor of their own version of PDF-based rendering. IIRC, it was initially done because they couldn't come to an agreement with Adobe on using Display PostScript, but OS X never shipped with it.

 

FYI: PDF is a encapsuled Postscript format. 

 

Apple surprised everyone including Adobe when they abandoned the pure Postscript Display because of high royalty, and switched to the more open model of PDF which has not royalty but still essentially the same as Postscript...  BTW OSX has retained its ability to read and write pure .PS Postscript files.

post #93 of 109
Quote:
Originally Posted by AppleInsider View Post

When Google's upcoming Android 4.1 Jelly Bean mobile OS hits devices in July it will incorporate "Project Butter," a processing framework designed to speed up UI responsiveness and graphics processing.

364

It's good of them to demonstrate how bad Android has been up until now:


Quote:
Originally Posted by AppleInsider View Post

Google I/O on Wednesday: "We declared a war on laginess."

Great, now they just have to deal with the other laginess of all the devices getting the upgrade.
post #94 of 109

That's not even that great of a demonstration. 

 

"Look at the choppy animations on the phone on the left and compare them to the slightly less choppy (but still choppy) animations on the phone on the right. Here, we'll show you that this is super scientific and highly professional by showing the use of a RED camera."

 

I bet if you scroll through a huge list or settings or a website, it'll still lag a lot. Show a real demonstration of real use and not superficial animations. What they show is not the lag most people are referring to. By showing those animations they don't do themselves any favors...the Jellybean animations are still choppy regardless so it suggests that things have only been slightly optimized. They may have won a battle in smoothing things out a little, but the war on lagginess is going to be a long one I fear.


Edited by carmelapple - 6/28/12 at 1:04pm

Samsung Galaxy series: Faster on a benchmark, not in your hand.

Reply

Samsung Galaxy series: Faster on a benchmark, not in your hand.

Reply
post #95 of 109
Quote:
Originally Posted by carmelapple View Post

That's not even that great of a demonstration. 

 

"Look at the choppy animations on the phone on the left and compare them to the slightly less choppy (but still choppy) animations on the phone on the right. Here, we'll show you that this is super scientific and highly professional by showing the use of a RED camera."

 

I bet if you scroll through a huge list or settings or a website, it'll still lag a lot. Show a real demonstration of real use and not superficial animations. What they show is not the lag most people are referring to. By showing those animations they don't do themselves any favors...the Jellybean animations are still choppy regardless so it suggests that things have only been slightly optimized. They may have won a battle in smoothing things out a little, but the war on lagginess is going to be a long one I fear.

My Galaxy Nexus on Jelly Bean is able to scroll smoothly through desktop optimized websites without so much as a hiccup in performance.

 

Smooth as.... butter.

Retina Macbook Pro - 2.6ghz

Galaxy Nexus - Jelly Bean!

Reply

Retina Macbook Pro - 2.6ghz

Galaxy Nexus - Jelly Bean!

Reply
post #96 of 109
Yo. Android user here. I will try not to be a fanboy though. I like Android but I'm not married to it.

With that out of the way, I'd like to share my experience with Jellybean (all six hours of it). It's already been shared by some people who went to GoogleIO and made into a flashable update for the Galaxy Nexus. Since I have a Galaxy Nexus I was able to download and install it this morning.

First off, I'll say that I was one of those Android users who didn't know what iPhone users were talking about when they complained about Android's scrolling. It always seemed smooth to me. I dismissed them as mindless fanboys. I have used iPhones before, a few times (mostly my dad's 4) and it seemed a bit smoother, maybe, but I couldn't quite put my finger on it.

Then I installed Jellybean this morning and my eyes were opened. It is incredibly improved. This is what Android should have been like since... I don't know, since a while ago. Is it better than the iPhone? Hard to tell since I am not an iPhone user, but I don't think it is. But it's a very noticeable improvement.

Clearly, Project Butter was meant to correct a deficiency in Android. And I think they've succeeded. What I don't get is why people here seem to be so mad about it. It's not like Apple owns exclusive rights to smooth scrolling and animations on smartphones.

At the same time, iOS 6 corrects a long-time iPhone deficiency - lack of turn-by-turn directions.

Overall I'd say iOS 6 and Jellybean are pretty similar in that regard. Evolutionary steps in improving their respective platforms. Clearing up loose ends and common complaints.
post #97 of 109

There was an article a while back that said that the reason Android seems laggy is because the core OS does not give priority to touch gesture. It gives equal weight to other system functions, so when there is a touch input from the user, the system may not respond quickly because system resources is being used up by other apps. Android is not very good at optimizing foreground versus background functions.

 

This is also the reason why you need a quad-core processor and 8-core graphics chip to be able to do the same thing that an old iPhone 3G can do. Android is not much different from Windows on Intel. Slow, clunky, power hungry. It's just poor design at its root.  

post #98 of 109
Quote:
Originally Posted by KDMeister View Post

There was an article a while back that said that the reason Android seems laggy is because the core OS does not give priority to touch gesture. It gives equal weight to other system functions, so when there is a touch input from the user, the system may not respond quickly because system resources is being used up by other apps. Android is not very good at optimizing foreground versus background functions.

 

This is also the reason why you need a quad-core processor and 8-core graphics chip to be able to do the same thing that an old iPhone 3G can do. Android is not much different from Windows on Intel. Slow, clunky, power hungry. It's just poor design at its root.  

 

The main issue with Android is everything is running inside a Java VM, and graphic rendering was using the main thread, so every wait in the code will halt UI refresh.  Beside DalvikVM has a pretty bad multicore-multithreading support.

post #99 of 109
Quote:
Originally Posted by d-range View Post

Not really, what you are describing is what double-buffering is for. Triple-buffering is adding yet another off-screen backbuffer, to be able to smooth out dips and spikes in rendering time. This way you don't have to drop frames when one or two frames take longer than 1/60th of a second to render. Since you are basically pipelining frames, you are also introducing latency (=lag), because when the content to render changes (e.g. by user interaction), there are still two frames queued that have to be flipped to the on-screen framebuffer before the frame with the new content can be displayed. 

Single-buffering (directly rendering to the framebuffer) is almost never used because it introduces drawing artefacts (you can see the screen getting 'painted'). Quadruple-buffering (or more) is almost never used because of the latency it indroduces, and because of the extra RAM it takes. Double and triple buffering are more or less standard fare in rendering, and have always been..

As I understand it, triple buffering is a hardware trick to decouple the GPU and CPU even more. That's because double buffering introduces a latency when copying the buffer, and the program is locked during that period. Adding another buffer makes it possible to continue the drawing immediately. See Wikipedia: http://en.wikipedia.org/wiki/Multiple_buffering .
Wikipedia could be wrong of course, but the explanation seems very likely.

I agree that the techniques used are standard, we could - by the way - continue the discussion in Dutch.

J.
post #100 of 109
Quote:
Originally Posted by BigMac2 View Post

 

MacOS X is a certified Unix'03 OS, OSX use FreeBSD and NetBSD for its user land which is called Darwin and is fully open source.  The UI is a 100% Apple-NeXT closed source creation of a Postscript vector based display, which is the only current UI who can drive the retina display on mobile and desktop, keeping normal resolution for unoptimized apps while boosting fonts resolution.  

 

Almost Only 10.6 Snow Leopard is currently listed as Unix'03 certified according to The Open Group http://www.opengroup.org/openbrand/register/xy.htm Darwin is not, btw. And there is also a binary layer adopted from FreeBSD, not just the userland. That is a kernel interface layer so that the FreeBSD utilities and tools can interact with the kernel, and other "unix" type access methods will work for lower level stuff. (Have not used it myself). And "UI is a 100% Apple-NeXT closed source creation of a Postscript vector based display" is not true. NeXTStep and OpenStep fell into that category. OS X is a PDF based vector based display UI system and no longer a Postscript based one.
post #101 of 109
Quote:
Originally Posted by BigMac2 View Post

 

FYI: PDF is a encapsuled Postscript format. 

 

Apple surprised everyone including Adobe when they abandoned the pure Postscript Display because of high royalty, and switched to the more open model of PDF which has not royalty but still essentially the same as Postscript...  BTW OSX has retained its ability to read and write pure .PS Postscript files.

 

PDF is not purely encapsulated postscript. It is much more than that. It is based off the same ideas as Postscript and includes a subset of postscript language. Based on Wikipedia, you may find this interesting: http://en.wikipedia.org/wiki/Pdf#Technical_foundations
post #102 of 109
Quote:
Originally Posted by Luca View Post

Clearly, Project Butter was meant to correct a deficiency in Android. And I think they've succeeded. What I don't get is why people here seem to be so mad about it. It's not like Apple owns exclusive rights to smooth scrolling and animations on smartphones.
At the same time, iOS 6 corrects a long-time iPhone deficiency - lack of turn-by-turn directions.
Overall I'd say iOS 6 and Jellybean are pretty similar in that regard. Evolutionary steps in improving their respective platforms. Clearing up loose ends and common complaints.

 

As an iPhone user and developer, I am not mad that Google attempts to fix issues, including lagginess. Good for them. Healthy competition keeps things going for everyone. We just like to laugh at all the Google-Droids who are so enamored with Android as to disavow any issues or problems.

And btw, "turn by turn directions" is not a deficiency in iOS. There are MANY turn by turn direction apps available and have been for a LONG time. The question comes down to -- is that a core OS function and should be taken care of by 3rd party apps (lots of choices and competition there). Or is it something that the core OS should do. I think Apple had it right in letting 3rd parties handle that and I fear that in iOS 6 we'll see 3rd party driving programs abandoned and no longer have choice.

post #103 of 109
Quote:
Originally Posted by MaroonMushroom View Post

My Galaxy Nexus on Jelly Bean is able to scroll smoothly through desktop optimized websites without so much as a hiccup in performance.

 

Smooth as.... butter.

Excellent anecdote. Provide proof. Use a RED camera too. 

Samsung Galaxy series: Faster on a benchmark, not in your hand.

Reply

Samsung Galaxy series: Faster on a benchmark, not in your hand.

Reply
post #104 of 109
Quote:
Originally Posted by chadbag View Post

 

PDF is not purely encapsulated postscript. It is much more than that. It is based off the same ideas as Postscript and includes a subset of postscript language. Based on Wikipedia, you may find this interesting:http://en.wikipedia.org/wiki/Pdf#Technical_foundations

 

PDF is more than "Base of the same ideas", it's a structured file format that can include multiple object types like Postscript and JPEG images, the PDF include most of the postscript language, only commands for driving hardware like flow control have been remove, so in terms of vector drawing, PDFs and Postscripts files are basically the same, it's a lot like C and Objective-C where you can have a Pure C code within an Objective-C object, you have pure Postscript object within the PDF structure.  At the end MacOS X PDF Display offers the same functionnality but without the licensing issue of OpenStep Postscript display.

post #105 of 109
Quote:
Originally Posted by jnjnjn View Post


As I understand it, triple buffering is a hardware trick to decouple the GPU and CPU even more. That's because double buffering introduces a latency when copying the buffer, and the program is locked during that period. Adding another buffer makes it possible to continue the drawing immediately. See Wikipedia: http://en.wikipedia.org/wiki/Multiple_buffering .
Wikipedia could be wrong of course, but the explanation seems very likely.
I agree that the techniques used are standard.

 

Pretty much so. Bit simplifyingly...

 

Reason for Triple buffering is that with double buffering hardware have to wait till sync doing pretty much nothing. Then new gfx buffer address is changed (or buffer copied, depends hardware) to point to the second (hidden one) buffer and first one can be used for drawing. 

 

In triple buffering, hardware can straight away continue drawing into second hidden buffer (third buffer) without waiting sync. 

 

Anything over triple buffering is often useless because there's always one ready and one unused buffer hardware can continue drawing to, unless ofcoz purpose is to do some processing with all of those frames.

 

Damn I miss old times 25+ years ago when coding was still fun and one had to do these and all other kinda tricks to squeeze performance out from things :)

post #106 of 109
Quote:
Originally Posted by Gazoobee View Post

I think the issue is that Google and all the Android supporters spent the first three revisions of the OS and the last five years or so claiming that these problems didn't exist, and now (by copying an Apple technique BTW), they attempt to fix them with a special "patch" that runs in the background constantly.  It certainly deserves a huge eye roll at the least.  

 

The OS should have been designed properly from the beginning, but then it wasn't really designed for the devices it actually runs on anyway was it?  

Making an interface smoother is different from saying that there was some lag in the last issue.

 

I'm sure you are a great programmer and you get everything right the first time. Even Apple had to improve on some things since the first release. They didn't get everything RIGHT right away. Certain things take time and effort. Can't we be a little fair in this regard?

post #107 of 109
Quote:
Originally Posted by imbrucewayne View Post

Making an interface smoother is different from saying that there was some lag in the last issue.

I'm sure you are a great programmer and you get everything right the first time. Even Apple had to improve on some things since the first release. They didn't get everything RIGHT right away. Certain things take time and effort. Can't we be a little fair in this regard?

You make some valid points but it's also a bit of a strawman since nothing is ever perfect. How long was it between the first Android OS demo to the Android OS demo with a HW accelerated UI? Apple's very first demo of the iPhone already had this baked in. From Apple's PoV this was a requirement for a shipping product because the fluidity of the UI is so important to the user experience. This was so good on a 412MHz ARM11 ARMv6 CPU with 128MB RAM that RiM didn't think it could possibly be real.

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply
post #108 of 109
Quote:
Originally Posted by msimpson View Post

 

I wonder if there are Apple fan bois who visit Android news & rumor sites to troll?     Are there any Android news & rumor sites?

 

Triple buffer with v-sync sounds like some overhead that only certain devices will be able to support.  Also sounds like the are grasping for straws because they are inherently flawed because they are running bytecode in a VM and the graphics are not that easy to handoff to the GPU units. 

 

Oh god, do they ever. It is usually the younger college-age trolls that do it, but it is rather annoying. It makes it worse that they are nearly illiterate when it comes to computers and tablet tech too. 

post #109 of 109
Quote:
Originally Posted by SolipsismX View Post


You make some valid points but it's also a bit of a strawman since nothing is ever perfect. How long was it between the first Android OS demo to the Android OS demo with a HW accelerated UI? Apple's very first demo of the iPhone already had this baked in. From Apple's PoV this was a requirement for a shipping product because the fluidity of the UI is so important to the user experience. This was so good on a 412MHz ARM11 ARMv6 CPU with 128MB RAM that RiM didn't think it could possibly be real.

So just because Android (pre google buyout) didn't get it right the first time, they are always wrong now? That is the real straw man. People look to what works, and what is most comfortable to them. iPad was more comfortable to me because it was so easy to use, but in that simplicity it lacked just about everything I needed. The biggest was a file management system similar to Mac or Windows PCs that almost all manufacturers prebuild into their ICS platforms. That to me is better than a fluid UI. I also hated that in order to hide apps on my iPad and iPad two i had to move them them to another screen or put them in a folder on a screen. I hated this. Why couldn't apple just make a folder in the system itself to hide the apps until I go to that folder? Until Apple allows users to have their own file management system like Android offers, allows us to drag and drop music, pics, and movies on to our iPads, and is more developer friendly to people who want to work on the IOS platform, Android wins my pocket book over. It would also be nice if Apple put a GPS in their wifi models for once too. 

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: General Discussion
AppleInsider › Forums › General › General Discussion › 'Project Butter' to improve responsiveness in Android 4.1 Jelly Bean