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.
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.
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
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?
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.
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.
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.
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.
Comments
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.
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.
Quote:
Originally Posted by MaroonMushroom
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.
Quote:
Originally Posted by chadbag
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_foundationsPDF 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.
Quote:
Originally Posted by jnjnjn
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
Quote:
Originally Posted by Gazoobee
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?
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.
Quote:
Originally Posted by msimpson
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.
Quote:
Originally Posted by SolipsismX
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.
Quote:
Originally Posted by SolipsismX
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.