The comments in these gadget threads are so polarized, it's positively toxic.
Not enough people have read an understood pg's essay on ID. People are making the gadget a part of themselves so they behave irrationally about it.
How about some Android graphics true facts?
101–109 of 109 posts
Re: How about some Android graphics true facts?
#102Earlier quoted context omitted.
You're beating a dead horse alright, but it's the wrong one. Garbage collection has never had anything to do with poor UI performances, and everything to do with making poor code stutter. When the GC starts hitting your framerate, it means you are creating far too many objects and far too frequently. Before ICS, android implemented the incremental GC that runs more often but for "negligible" sub-1ms lengths. If you a…
Users don't distinguish between poor UI performance and"code stutters". The "negligble" sub-1ms stutters are a real problem in practice. and it's not just limited to poor code. Sometimes, no matter what you'll see GC being called, there's no way around it. There are background threads that are doing all sorts of things, which very well might be getting GC'd. Theres also a lot of things you can't reasonably avoid, lik…
Poor choice of words on my part. It's not "poor code" but "inadequate code". The Android graphics API is, overall, inadequate for avoiding GCs at all costs. Java on the other hand, is not necessarily inadequate. The issues with GC and the Bitmap class are a good example: Bitmaps aren't designed to work at the lowest & fastest level but at the highest and easiest level.
Nothing beats primitives and buffers - the performance gap between the two methods is huge, that's true, but it's not a showstopper.
I don't recall gcs in other processes hurting my apps performances though. With that said, if I'm going to write a game, I'll make sure none of the threads in my process will trigger a GC past the loading/splash screen. This means no instanciations of any additional iterators, collections, Strings... The overhead of allocations is almost as bad for the framerate as the GC anyway.
Re: How about some Android graphics true facts?
#103Earlier quoted context omitted.
The number of apps you have installed has no significance what so ever on scrolling. Just FYI.
I think he means the number of apps running in the background. For example, if you have the Groupon app making constant push notifications to you, that's expensive.
Also worth noting that the iPads in the Apple stores are normally stuffed with apps for people to try, rather than just plain installs.
Re: How about some Android graphics true facts?
#104Earlier quoted context omitted.
Downmodders: Can you explain why? My point is, software is rendering the graphics. Either it's software running on one chip, or it's software on another chip. That's irrelevant. What matters, is how fast the graphics are rendered.
>Either it's software running on one chip, or it's software on another chip. That's irrelevant. No, its not irrelevant. The terms have meaning, regarding the separation. And while it may technically be a misnomer, feigning ignorance to the misnomer to try and point out the misnomer to people who already know about it is not only arguing semantics, but doing so in least constructive way possible. To address your other…
I'm not a dev, but doesn't Apple's Open CL come into play here? is there silicon in iDevices in addition to the GPU which can be used for HW acceleration, whereas Android can only make use of the GPU for this?
Re: How about some Android graphics true facts?
#105Earlier quoted context omitted.
I found a better source arguing that iOS is ahead (at least in February of 2011): http://www.comscore.com/Press_Events/Press_Releases/2011/4/A... This is now 3 sources claiming iOS has greater share than Android, and even if they are a bit outdated, it's proof that the 60% share vs 15% share cited in many articles refers only to the phone wars (most articles I've seen eventually mentions the words "smartphone").
There is no real confusion, except what you seem to be trying to create. The BRG report is using one companies analytics product (which is embedded in apps). Plainly that is more popular on iOS than Android, but we've seen that before - most people on Android use Google Analytics, so 3rd party analytics aren't reliable when comparing them. Those Comscore stats are nearly a year old. A more recent one shows Android at…
Your stats refer to smartphones only whereas mine specifically says iPod touches, ipads, and iPhones. Given that the company doing the research is the same in both, but the labels are different, this difference could hold significance. Furthermore, if your table actually means what it's supposed to, it would mean android went from 10% share in February to 42% share in June.
Also, there are many factors at play as any Stats student knows. Simply making assertions that android users are misrepresented could be dangerous.
Re: How about some Android graphics true facts?
#106So, in summary, "We have hardware acceleration, have had it for a long time, but it isn't the reason android interfaces are almost universally clunky. We actually have no idea why that is." I don't use any apple products but I get tired of Google touting how much better 4.0 is when most people are locked into phones running 2.2 or 2.3 for years into the future.
A lot of the 2011 phones should be updated to Android 4.0, and the ones who bought them in 2010 will upgrade next year to Android 4.0 phones.
If I hadn't had a family member willing to give up their upgrade for me, I would be locked into a phone running 1.6 until May 2012, one which has no custom ROMs.
Re: How about some Android graphics true facts?
#107Earlier quoted context omitted.
It's a definitional thing. "Works" at (say) Microsoft or Google means "produces a correct result at the end" whereas it means something quite different at Apple. The most egregious example I've seen of this is the way Mac OS filtered mouse movement data from the beginning, but it still doesn't feel right on Windows (and wasn't even in the ballpark until around Windows 98/NT4). (And, by contrast, the Amiga had pretty…
You say that as if that was a fact but in reality is nothing but your opinion. I can barely stand the, in my opinion, horrible mouse acceleration in OS X and knowing apple I can imagine that they feel that giving me the option to disable it isn't user friendly.
[deleted]
Re: How about some Android graphics true facts?
#108Earlier quoted context omitted.
Hm, I don't remember that ever happening to me in the last ~2 years with two devices that I've used most: nexus one and motorola defy. But ok, I grant you that it can happen. So what? I've also seen an iPhone freeze completely. That's funny. I use a Nexus S on a daily basis, and compared to my primary phones I've used over the last 3 years (iPhone 3GS, 4, and now 4S), the touch screen is awful. The incontrovertible t…
But you're forgetting the other big screen criteria people have: "not from Apple". Once you factor that in, the Android platforms all fare much better. :)
Or rather, not from a monopolistic company bent on calling users criminals for accessing their own devices.
But yeah, if you agree that that describes Apple to a T, or maybe a P, then "Not Apple, (or Microsoft, or ...)".
Re: How about some Android graphics true facts?
#109Earlier quoted context omitted.
There is a big difference between hardware and software rendering. Software rendering has you plotting each pixel individually and writing to the framebuffer. Hardware rendering uses specialized APIs and hardware to dramatically speed up drawing and transformation functions.
No, they both involve software, writing to a framebuffer. (By software, I mean code - software/firmware/etc). A crappy 'hardware' accelerated GPU can be slower than a 'software' framebuffer write. My point was that saying "It's hardware accelerated" is meaningless marketing speak.
Indeed, Apple's Mac OS X QuartzGL framework (GPU accelerated drawing/rasterisation) is slower than the equivalent CPU-based Quartz framework in may cases.
You're being shafted by downvoters who don't really know what they're talking about.