"Android graphics true facts"
December 6, 2011 2:33 PM   Subscribe

The day before last, Dianne Hackborn, a software engineer from Google, posted a lengthy essay on Google+ about Android UI rendering also touching on the hardware accelerated UI debacle. Not to let sleeping dogs lie, one of the previous Android interns, Andrew Munn, posted a reply regarding other areas where Android needs to improve. Both posts provide an absolutely fascinating first-hand look into how the Android UI works.
posted by Talez (57 comments total) 19 users marked this as a favorite
 
Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.


Good read, thanks.
posted by Blazecock Pileon at 2:42 PM on December 6, 2011 [1 favorite]


And here's some clarification on that post's apparent inaccuracy regarding iOS graphics: http://jstn.cc/post/13829720580
posted by thedaniel at 2:44 PM on December 6, 2011 [1 favorite]


What I find amazing is how even a few milliseconds delay can make the difference between something seeming smooth and something seeming intolerably slow and laggy. The appearance of user responsiveness is crucially important.
posted by Nelson at 2:47 PM on December 6, 2011 [3 favorites]


Putting any significant work like network requests or data storage into background threads is a good pro-tip for iOS development. And NSThread, NSOperation, blocks and GCD make it pretty simple to do. Keeping the UI running smoothly makes the user think the computer is running faster, because the UI is all the user interfaces with. A choppy UI gives the impression that everything else going on is dirt slow, as well.
posted by Blazecock Pileon at 3:14 PM on December 6, 2011 [2 favorites]


Dianne's post is accurate and informative, and I think she does a good job of arguing that hardware acceleration isn't going to be a magic cure for Android lagginess. But I think Andrew does a better job of getting to the heart of the matter, which is to explain why Android has a demonstrably laggier UI than everyone else.

It's interesting reading some fairly well-informed comments that argue against Andrew's thesis while entirely missing the point. One guy, Chi-Ho Kwok, essentially says that it's not Google's fault because Android developers are being sloppy about doing too much computation in the UI thread and similar forms of developer abuse. He's a typical developer who gets angry when platform designers make decisions for him. But like I said, this missed the point: the end effect is that Android and Android apps do not have a smooth UI, and that's what consumers care about. If Google wants Android to prevail, they will have to do something about that, even if it means stifling the "vaunted creativity" (i.e. sloppy practices) of software engineers (I say this as a software engineer). This aint the Wild West of PC development; rather, this is platform makers inviting us into their walled gardens to plant a few flowers. There's no turning back for this particular market.
posted by Edgewise at 3:16 PM on December 6, 2011 [5 favorites]


I like the part where he says WebOS is smooth. I'm looking at things not happening and screen clicks not registering on my Veer right now, and ruefully chuckling.
posted by 1adam12 at 3:18 PM on December 6, 2011 [3 favorites]


The thing I find most interesting about the walled garden metaphor in mobile development is that what came before it was prison visitation, not freedom. The grim days of flip-phones running crap Java ports of Pac-Man that you paid $4.99 to rent for a month? Those were like six years ago.
posted by verb at 3:19 PM on December 6, 2011 [9 favorites]


Smartphones existed before the iPhone. (No matter what some people on Metafilter might claim.)
posted by kmz at 3:28 PM on December 6, 2011 [4 favorites]


If Google wants Android to prevail, they will have to do something about that

They are the highest selling smart phone platform already. So while making things more responsive will help (and frankly modern devices like the SGS2 and the new Galaxy Nexus are fine) it's not like people aren't buying the things.
posted by markr at 3:30 PM on December 6, 2011 [4 favorites]


So, in a nutshell: iOS gives you enough rope to hang yourself, but Android has already hung itself and you just get to use some of the leftover rope.
posted by mullingitover at 3:32 PM on December 6, 2011 [5 favorites]


Huh. I thought this was about Android and not igadgets.
posted by Big_B at 3:34 PM on December 6, 2011 [1 favorite]


I have never noticed Android device UI being slow. It's certainly never been one of my complaints.

You know what's slow? The internet, when I'm not getting a 4G connection (and occasionally even then).
posted by Foosnark at 3:44 PM on December 6, 2011 [1 favorite]


Dianne Hackborn, a software engineer.

You can't make this stuff up.
posted by Splunge at 3:45 PM on December 6, 2011 [11 favorites]


They are the highest selling smart phone platform already.

Are you talking about total units or current rate of sales? I don't know the figures for either, but I'm guessing you mean the latter. If so, I wouldn't say that's a fair comparison, because the iPhone arrived on the market long before Android phones. If you mean the former, then that's interesting news to me. Either way, you're right in saying they aren't exactly struggling, so I suppose I meant that if they want to see significant improvement.

I have never noticed Android device UI being slow.

If you compare the UI on an iOS device to an Android device, you will definitely notice that the iOS device has smoother animations. This isn't about having to wait a few seconds for an app to start, it's about the UI experience, which is definitely smoother on non-Android devices. In other words, things like scrolling lists, screen rotation, etc. I have heard a lot of talk that ICS should improve things, so...bated breath.
posted by Edgewise at 3:54 PM on December 6, 2011 [1 favorite]


"Google believes that things should be fast. That’s a driving philosophy behind Google Search, Gmail,"

"It’s why buffering on Youtube is something most of us remember, but rarely see anymore. "

I recently had to switch to using an email client (something I last used in 1999) with gmail because their latest redesign slowed things down horribly, and am in the process of moving to a different email provider.

Youtube buffers frequently, and for no apparent reason decaches and stutters when going to & from windowed to full-screen.

If speed is their core philosophy then they are in serious trouble.
posted by aerotive at 3:55 PM on December 6, 2011 [6 favorites]


Please let there be a Replicant intern.
posted by jimmythefish at 3:56 PM on December 6, 2011


I have never noticed Android device UI being slow. It's certainly never been one of my complaints.

You know what's slow? The internet, when I'm not getting a 4G connection (and occasionally even then).


This, many times over. Problems with coverage? Endemic. Problems with the UI? None. In fact, my phone can very smoothly, rapidly and stylishly tell me when I've hit yet another gap in T-Mobile's coverage, or entered a building with some kind of communications-proof shielding.
posted by gimonca at 3:57 PM on December 6, 2011 [2 favorites]


Interesting reading. Funny how hardware acceleration/augmented compositing is often touted as the solution to making something more responsive - so it's nice to see both articles blow this away.

I was going to try and draw some parallels between how the Amiga's Intuition GUI system was designed with UI-responsiveness pretty much at the forefront, although this is pretty much how Andrew explains things in his article (e.g. IOS with dedicated UI threads, realtime priority, etc.).
In reality, Andrew states that "iOS is 100% smooth even when installing apps" which isn't entirely correct - just setting something installing on my iPhone 3G causes everything to lag in a painful and crippling manner... and also, the Amiga interface responsiveness probably didn't work quite as spectacularly smoothly as my rose-tinted nostalgia would like to suggest...

Is there a Godwin-esque equivalent for computing discussions, relating to the speed at which someone compares something to the Amiga? If not, there should be; Jay Miner's law, perhaps?
posted by Chunder at 3:57 PM on December 6, 2011 [3 favorites]


aerotive: "Youtube buffers frequently, and for no apparent reason decaches and stutters when going to & from windowed to full-screen."

This happens because YouTube starts playing at 360p in the window, but when you switch to fullscreen it dumps the cache, automagically (and by automagically I mean infuriatingly) switches to 480p, and starts buffering all over again.
posted by mullingitover at 4:08 PM on December 6, 2011 [5 favorites]


kmz: "Smartphones existed before the iPhone. (No matter what some people on Metafilter might claim."

That's… cool, I guess? Right? I guess it's cool that you're itching for an argument, so you're just tossing stuff out there.

Really interesting articles there. Fascinating to finally find out what it was, exactly, that causes the difference between the illusion of direct manipulation and the impression that the screen is following your finger, and how so little time makes such a difference. I'd always wondered how it was that the newest Android phones at stores always felt at least a little laggier than the first-gen iPod Touch I owned years ago. The comment on NeXTSTEP and how its mouse cursor was always responsive, even under heavy loads, seems to explain a lot about that too.

Be cool to see if the Android team actually takes his suggestions seriously, though it seems like that would require something of a fundamental rewriting of the OS from the ground up. It would be huge in the end (and remove at least one major bit of fodder for the "Android is iOS for parents who always buy the wrong thing" camp) but given Google's track record in general over the past few years, I do not expect them to fix this in any meaningful sense.
posted by DoctorFedora at 4:09 PM on December 6, 2011 [3 favorites]


For me buffering takes a back seat to "An error has occured, please try again later."
posted by Splunge at 4:10 PM on December 6, 2011


Android surpassed iOS like almost two years ago in U.S. market share, Edgewise, before that internationally. Java has never done graphics particularly efficiently sadly.
posted by jeffburdges at 4:11 PM on December 6, 2011 [3 favorites]


Sorry, I came as fast as I could, as I heard someone was saying less-than complementary things about a brand I like! Who do I fight; do we pair off, or is it shirts versus skins?
posted by Dark Messiah at 4:22 PM on December 6, 2011 [14 favorites]


Hacker News commenters claim that Andrew Munn's explanation for lagginess is wrong.
posted by martinrebas at 4:23 PM on December 6, 2011 [1 favorite]


That's… cool, I guess? Right? I guess it's cool that you're itching for an argument, so you're just tossing stuff out there.

Did you miss the comment directly above mine which implied that all there was pre-iPhone were dumb flip-phones?
posted by kmz at 4:27 PM on December 6, 2011


I get called on to refactor code and move heavy processing to worker threads a couple times a year. Someone will have an app that locks the entire UI while it is cranking through XML or something, move all that stuff to worker threads and it is like a miracle. Then I start adding stuff like owner drawn progress bars and make it slow again, but at least it looks cool.

Anyway you guys are right nobody writes an app with worker threads from the start, it just makes everything a pain in the ass to debug. Everyone holds off on threading until you have to do it. Every time I do it I just hope hope they don't have all intensive processing in the button click handlers.

The fact that they are deploying to a phone is not going to change developer habits.
posted by Ad hominem at 4:36 PM on December 6, 2011 [2 favorites]


kmz, I actually sort of did, though at the same time the problem with Android really is fundamentally that it is still built on the underpinnings of pre-iPhone "smartphones," which by modern standards are merely kind of bright at times, which is a large part of the point of the previous post — the modern smartphone really is very much iPhone-based in much the same way that the modern GUI is very much Macintosh-based (in the 1984 sense), and it's kind of silly to try to argue otherwise other than for reasons of pedantic semantics in order to be technically right.*

*the best kind of right
posted by DoctorFedora at 4:39 PM on December 6, 2011


why Android has a demonstrably laggier UI than everyone else.

Because I cover every bit of screen space with Minimalistic Text widgets to launch everything and display all my information so my tablet looks like a Tricorder? It's worth the slowness.

now, if I could just get it to make that sound.
posted by fuq at 4:45 PM on December 6, 2011 [1 favorite]


Youtube buffers frequently, and for no apparent reason decaches and stutters when going to & from windowed to full-screen.

The former is usually not something we can do much about. We have an amazingly good CDN (content delivery network), but we don't control your ISP or connection enough to guarantee fast video delivery. There are all sorts of things we do / are doing, but most of the time this is a last-mile issue and not a coding-related issue. Sometimes these are actual bugs, either in the player/page code or in Flash or HTML5, and those we try to stamp out pretty aggressively. Last mile / connectivity issues are something Google does look at (look at the Kansas City / fiber initiatives) but thats more in the politics/business realm, I don't know the challenges there. [I'm not trying to put all the blame on connections, but honestly when you're talking about video it still matters in a way that it rarely does for, say, search]

The latter is what mullingitover says --- the client switches resolution when going to fullscreen. Different resolutions are entirely separate streams/files, so the existing buffer is meaningless (well, not fully, but properly doing a kind of blend of the two streams to switch seamlessly is nontrivial for a host of reasons).
posted by wildcrdj at 4:57 PM on December 6, 2011 [2 favorites]


You mean this sound?
posted by CheeseDigestsAll at 5:07 PM on December 6, 2011 [1 favorite]


Wildcrdj: could you do something about the "we guessed your region!" alert that pops up?because dismissing that also causes the whole page to dump cache and reload.
posted by fightorflight at 5:12 PM on December 6, 2011


Did you miss the comment directly above mine which implied that all there was pre-iPhone were dumb flip-phones?

I said no such thing. I apologize if you took my comment that way, it wasn't intended in quite as sweeping a fashion. It's certainly fair to say that the phone ecosystem was nowhere near as heavily tilted in favor of smartphones then, as it is now, and that flip and bar-of-soap phones were much more common.

I was actually reflecting on the fact that people referred to any sort of phone ecosystem as a "walled garden" in the current climate; Android, iOS, WebOS, Windows Mobile Smart Thing Of The Moment, etc. are all orders of magnitude less constrained than previous generations of phones. The availability of third-party software for them, the ability to take advantage of tools and resources not intended or explicitly approved by the manufacturers (via robust web browser support, etc) is simply no comparison to the grim old days.

But I'm happy to go shout mean things about a random platform if that would make you feel better.
posted by verb at 5:14 PM on December 6, 2011 [2 favorites]


The latter is what mullingitover says --- the client switches resolution when going to fullscreen. Different resolutions are entirely separate streams/files, so the existing buffer is meaningless (well, not fully, but properly doing a kind of blend of the two streams to switch seamlessly is nontrivial for a host of reasons).

Follow-up question. Why in God's name does my 8mbps connection default to 360p when there are higher resolutions available? I realize you don't want to actively antagonize people with slower connections/capped internet, but if there's an option to "choose the best option for me" shouldn't do something other than always choosing the suckiest available option?
posted by Holy Zarquon's Singing Fish at 5:17 PM on December 6, 2011


This happens because YouTube starts playing at 360p in the window, but when you switch to fullscreen it dumps the cache, automagically (and by automagically I mean infuriatingly) switches to 480p, and starts buffering all over again.

You can turn this off in your settings! I was so happy when I learned that!
posted by zeek321 at 5:23 PM on December 6, 2011


Hacker News commenters claim that Andrew Munn's explanation for lagginess is wrong.

This has been interesting to watch play out. Hackborn, who is a key Android dev, explains some things, then a guy who interned there for a bit posts his own long explanation in which key points are wrong, and now both posts are all over the blogosphere with Munn's post considered gospel.

From what I've seen, the number one reason that some iphone apps are more responsive than some android apps is that iphone developers are putting a higher priority on responsiveness.
posted by markr at 5:49 PM on December 6, 2011 [2 favorites]


My first generation Droid was pretty slow at times but my current Incredible 2 seems as fast and responsive as I'd want it to be and it's actually a low end phone compared to some of the newer ones. If there's any lag, it's below the threshold where I can perceive it.
posted by octothorpe at 5:57 PM on December 6, 2011 [1 favorite]


What I find amazing is how even a few milliseconds delay can make the difference between something seeming smooth and something seeming intolerably slow and laggy. The appearance of user responsiveness is crucially important.
It says people's tolerance has gone way down :P On my new phone I've noticed the home-screen animations can get a little choppy when I go 'back' to home and scroll around, speeding up after a bit (I assume when everything is loaded). However, I don't really care that much.
The thing I find most interesting about the walled garden metaphor in mobile development is that what came before it was prison visitation, not freedom. The grim days of flip-phones running crap Java ports of Pac-Man that you paid $4.99 to rent for a month? Those were like six years ago.
Hah! I actually emailed my carrier at the time (US Cellular) about potentially writing some apps for the phone I had at the time. It was my first phone with a color screen and ran BREW apps.

They emailed me back, like two years later saying, basically, "sorry for taking so long to reply! We're not adding any new developers" It was pretty strange, why even bother replying after 2 years jus to tell me you don't want to let me put apps on my phone?
Youtube buffers frequently, and for no apparent reason decaches and stutters when going to & from windowed to full-screen.
What's worse is that it depends on the video you're watching. Some load slowly, while others load right away even at 1080p.
Java has never done graphics particularly efficiently sadly.
That's not really true. Java's Swing GUI framework was slow, but if you're doing raw 2d graphics it's fine (so is OpenGL with jogl). Android doesn't use Swing, so that's a non-issue. Also android converts java into another bytecode format before it runs.
Anyway you guys are right nobody writes an app with worker threads from the start, it just makes everything a pain in the ass to debug.
Um… I do. Actually, the major java program I wrote was a space-invaders style video game where each sprite had it's own thread. I had no idea what I was doing, but I was a big fan of threads :)
posted by delmoi at 7:23 PM on December 6, 2011 [2 favorites]


The tumblr with the broken link from further up is amazing.

Hmph. I'm not often jealous of someone else's life...
posted by stratastar at 8:01 PM on December 6, 2011 [2 favorites]


The Android Java apis have good message passing libraries available. Actors can be thought of as separate threads with a mailbox associated with them. They react to incoming messages, do work, and then send messages to other places. A printer spool is an actor. It reacts to incoming files, interprets the postscript of the file, and then sends the interpreted postscript to the printer. It's easier to debug programs that have actors that manage single resources, rather than having multiple threads each sometimes interacting with the same resource.
posted by DetriusXii at 8:03 PM on December 6, 2011


That explains the *meh* responsiveness of the Fire.
posted by quadog at 8:48 PM on December 6, 2011 [1 favorite]


My phone is by no means the latest and greatest but, as others have said, UI performance is never really an issue. 4G service that drops out while I'm standing perfectly still on the other hand?

Oh and 1adam12, sorry to hear that about your Veer. With some judicious tweaking on my TouchPad (which I had originally intended to rebuild with Cyanogen) WebOS has been a pleasure to use.
posted by JaredSeth at 9:44 PM on December 6, 2011


It seems to me this is a fairly straightforward trade-off.

When user input and background processing are going on at the same time, iPhones give a higher priority and more processor cycles to the user input, Android gives more to the background processing.

Personally I prefer the Android way, as I'm often loading multiple web pages in the background or running multiple apps. Other people will prefer the iPhone way.

It seems a bit silly to claim that one way is intrinsically better than another. This person is arguing that iPhone does it better and Android is somehow old-fashioned. But you could argue it the other way around too: that iPhone is old-fashioned because it doesn't support multitasking so well.

Pay your money, take your choice.
posted by TheophileEscargot at 12:50 AM on December 7, 2011 [1 favorite]


With some judicious tweaking on my TouchPad (which I had originally intended to rebuild with Cyanogen) WebOS has been a pleasure to use.

A GUI-based OS shouldn't require any tweaking to be a pleasure to use. Though to be fair, I also tweaked my TouchPad to make WebOS faster. (Also the Cyanogen build for it is alpha, but dual boot, so you can go back and forth if you wish.)
posted by ZeusHumms at 1:14 AM on December 7, 2011


Oh I should ad:
Anyway you guys are right nobody writes an app with worker threads from the start, it just makes everything a pain in the ass to debug.
Oh, also I've only written one single program for android. It was a counter. You ran the program and it showed a counter that counted up every 10ms. I used a worker thread to do the counting and updated the UI using (I just looked up the source) android.os.Handler way to inject stuff into the UI thread.

IMO it's much more difficult to take a single threaded design and make it multithreaded if it's too slow then it is to take a multi-threaded design and make it single threaded (you just call the run functions inline) if you need to debug it or if it's not working.
When user input and background processing are going on at the same time, iPhones give a higher priority and more processor cycles to the user input, Android gives more to the background processing.
That's not exactly true. It sounds like this Andrew Munn guy was just blowing smoke out his ass. You can make stuff go fast with any threading model provided you're really careful. It sounds like the guys who wrote the browser on iOS were, while the android browser developers made other trade-offs (using an OpenGL display list rather then Tiles)

By the way, the, er, precociousness of this Andrew Munn guy is a little annoying.
However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely unacceptable. It should be priority #1 for the Android team.
I mean, a college kid who worked on this project as an intern is saying Google needs to do a comparability breaking rewrite (likely the old API would be there, but like windows with tons of cruft, it would just end up as bloat so old apps would work, while new ones wouldn't be backwards compatible) in order to get a few extra frames that Moore's law might handle anyway.
posted by delmoi at 1:40 AM on December 7, 2011 [3 favorites]


Yes delmoi and he is ready to manage it.
posted by CautionToTheWind at 2:55 AM on December 7, 2011 [1 favorite]


Like others, I must have the version of Android that is not laggy but is in fact, as responsive as I'd expect.
posted by juiceCake at 7:41 AM on December 7, 2011 [3 favorites]


What I find amazing is how even a few milliseconds delay can make the difference between something seeming smooth and something seeming intolerably slow and laggy. The appearance of user responsiveness is crucially important.

Is it really, or is it marketing telling you it's crucially important.

Honestly, I know my Android phone has a split-second or sometimes multi-second lag. I couldn't care one bit.

Do you press the "close door" button on elevators?

the end effect is that Android and Android apps do not have a smooth UI, and that's what consumers care about.

Again, do they really? What are we basing that assumption on?

I guess I'm just echoing Theophile Escargot.
posted by mrgrimm at 11:50 AM on December 7, 2011


The tumblr with the broken link from further up is amazing.

That would be Justin Ouellette, creator of Muxtape.
posted by mrgrimm at 11:51 AM on December 7, 2011


mrgrimm: "Honestly, I know my Android phone has a split-second or sometimes multi-second lag. I couldn't care one bit."

You kids are spoiled, with your lag-free iphones and your hula hoops. Back in my day the phones ran on coal, didn't respond to user input for weeks, and we liked it!
posted by mullingitover at 1:33 PM on December 7, 2011


Again, do they really? What are we basing that assumption on?

There are numerous end users and developers who acknowledge and are upset that the Android interface is slow.
posted by Blazecock Pileon at 5:20 PM on December 7, 2011


They don't know that there is anything better. If you haven't used an iPhone or an iPad extensively, you may not know that Android's behavior is not as nice.

I have used both extensively and I think they both perform admirably. It hasn't for a moment made me think Android is not nice. Others are welcome to an opposing opinion of course but like my own opinion it doesn't mean anything more than that though, it's just a different point of view. I look forward to the absolute hilarity of proclamations like the G5 processor is 10 times faster than anything Intel can make which I actually saw back in the day (those people must have had a culture shock when those god awful slow Intel chips were now in their Macs). I find this sort of high wankery almost as entertaining as William Tapley.

I mean seriously, they? What's next? Manufacturers of elevators and pages upon pages about how one makes a smoother ride than the other. Are you an Otis or Schindler individual?
posted by juiceCake at 5:41 PM on December 7, 2011 [3 favorites]


Others are welcome to an opposing opinion of course

Just countering the notion that no one cares that Android is slow, the observation of this not being subjective, so much as fact-based. People who use and develop for Android seem like they do care (at least enough to post their concerns; see previous links for a handful of data points). Further, the very two people who are the subject of this FPP are software engineers who have worked on Android and acknowledge the issue is real enough that they both are trying to reason out why the UI is slow, while coming to different answers about why, and how it might be addressed in future releases.

Are you an Otis or Schindler individual?

I guess we can dismiss all the Android users asking why Android is slow, but subjective opinion about elevators has no bearing to what the two software engineers associated with Google's products have observed and made hypotheses about.
posted by Blazecock Pileon at 5:56 PM on December 7, 2011


You all know you can turn off all the animations in Android right? Problems solved!
posted by fuq at 5:28 AM on December 8, 2011




Diane Hackborn has made another post on Android internals. Another interesting read, with perhaps a tiny swipe at Munn:

"I hope this helps people better understand how Android works. And just to be clear again from my last point -- I am not writing this to make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic."
posted by markr at 1:07 AM on December 12, 2011 [3 favorites]


Just countering the notion that no one cares that Android is slow.

Who said that no one does? But the statement from your wonderful link (glad to see you're linking now rather than not) that they just don't know is ridiculous. Plenty of people are quite happy with it. This does indeed make it subjective. If your happy with the speed this does not mean you are wrong about it and you just don't know.

I guess we can dismiss all the Android users asking why Android is slow.

I don't know who "we" are but I would not dismiss them. If people feel it's slow then they feel it's slow. Just as people feel it is not. That is all. I believe some people find it slow and that is fine. The fact is that some do not. That too is fine. I am sad that you can't seem to live with that and am truly sorry for your struggles. I hope you can recover.
posted by juiceCake at 7:54 AM on December 13, 2011 [1 favorite]


Apple loses their Australian case against Samsung (/.)

Well at least Apple is being helpful to Samsung letting them know how they could have built a different tablet for example:

The tablet alternatives Apple felt Samsung should have explored are similar:
  • Overall shapes that are not rectangular with four flat sides or that do not have four rounded corners
  • Front surfaces that are not completely flat or clear and that have substantial adornment
  • Thick frames rather than a thin rim around the front surface
  • Profiles that are not thin
  • A cluttered appearance
Bless their hearts.

Source
posted by juiceCake at 8:03 AM on December 13, 2011


« Older a bit of a trickster   |   "Weasel Wednesday" comes a day early Newer »


This thread has been archived and is closed to new comments