Software Preload

The 2X in the form we reviewed it was running Android 2.2.1 and a custom LG skin. Eventually the 2X will get a major software update that brings it up to 2.3. There are some design elements which are common between the 2X and the other LG Android phone we’ve tested, the LG Optimus One. Those similarities are the way applications are grouped, inclusion of power options in the notifications shade, but pretty much stops right there.

Most of the LG skin is actually pretty tasteful. Status icons for signal, battery, and network status are colorful and non-stock, and the color-on-black theme is vaguely reminiscent of Android 2.3. One of the things I’m a fan of is that LG made the network status indicator show H for “HSPA,” and 3G for UMTS—there’s a distinction between those two network modes that stock Android doesn’t draw unless you dig down into “About” or use a widget.

The theme emulates some of iOS in a rather annoying fashion, including a four-icon dock at the bottom that persists across all pages and isn’t readily user customizable. Phone, contacts, messaging, and applications are what always are going to be at the bottom. Even if you bring up the applications launcher, those elements persist, though “applications” changes to “home.”

The launcher organizes applications in a slightly odd way with two discrete categories. System applications include those that come preinstalled as part of LG’s preload. You can’t change or remove these, they’re special, and there are 43 of them. I’m actually a bit put-off by how much bloat there is here, including “browsing protection” and another separate “f-secure” mobile security application, all of which can’t be removed. I was hoping that “preloaded apps” would let me uninstall preloaded apps, instead it appears to inexplicably do absolutely nothing. There’s Facebook, Twitter, and MySpace all of which are “for LG,” presumably to accompany preinstalled widgets. Why you’d use these instead of the official versions of the respective apps is beyond me.

Down below “system applications” is a category simply named “Downloads.” It’s under this category and completely discrete section that things from the marketplace, internet, or otherwise installed will appear. Applications are ordered in here in the order they’re installed by default, which is puzzling. Notice that some applications also have a blue N above their logo—N ostensibly stands for New, as the bubble goes away after initial launch. You can force things to be organized alphabetically by performing a category reset in the menu. There’s also the option to view apps in a horizontal grid or list.

It’s a strange dichotomy that LG sets up with this launcher scheme that divides “downloaded” apps from “system applications,” one that’s made on no other Android device I’ve ever seen but the Optimus One. The end result is that most of the stuff I want (you know, since I just installed it) is at the very last page or very bottom of the list, resulting in guaranteed scrolling every single time. If you’re a power user, just replace the launcher with something else entirely.

The theme inside the messaging application is also honestly somewhat of an obvious attempt to emulate iOS. The dialog takes place in chat bubbles that are strikingly similar. What’s frustrating here is that the font is huge, and the shading and space between those bubbles is positively gigantic, which makes it hard to see the whole dialog.

The 2X ships with just LG’s own custom keyboard as an available option. The keyboard isn’t multitouch and offers only basic correction, but is visually more appealing than the stock Android keyboard. It works but it’d be nice to see Swype on here, but you can grab that yourself if you’re lucky enough to be in the beta program. I immediately went and grabbed Swype just out of force of habit, but found that occasionally input from the keyboard in the messaging application didn’t actually make it into the compose box. I could tell the keyboard was receiving input, but characters simply wouldn’t appear until I switched input methods back and forth at least once. Other small glitches included messages I sent sometimes not resulting in the dialog auto-scrolling to the latest. SMS is one of those things every phone has to really get right to be usable, and I feel like there’s a bit more refinement needed here.

The dialer also has some LG theme going on, but the differences between it and stock are purely aesthetic. White buttons, a link to messaging instead of voicemail, and moved backspace key are really it.

Back on the home screen, by default LG has a pretty decent preload of widgets and shortcuts. Their weather and clock widget is actually the best I’ve seen yet and has already been ripped from system dumps for use on other Android phones—after time with it, I can honestly understand why. Another extra is the ability to totally clear all the widgets and shortcuts from a particular homescreen from the longpress menu.

There’s also an FM radio application which works off the previously mentioned BCM4329 stack. Standard fare here with the requirement that you have some headsets plugged in to double as the antenna. The radio application has an auto-scan function for detecting local channels, and also pulls down RDS text.

Alongside the normal marketplace also is NVIDIA’s Tegra Zone marketplace which is home to apps and games optimized for Tegra 2 based smartphones. In general, they’re differentiated from normal applications by having more detailed geometry, textures, shaders, and content. Tegra Zone isn’t fully launched yet (it goes live when the 2X starts shipping stateside, I’m not sure whether it’s live on the Korean version), so we couldn’t install applications from it directly, but could still explore the application and try sideloaded copies of some games from the market.

One of the interesting things done in the Tegra Zone marketplace is drawing a distinction between user contributed reviews and professional ones. As games get closer to their console and desktop counterparts (and probably more expensive), that could definitely be useful.

We were able to try Galaxy on Fire 2 and Dungeon Defenders, two of a number of titles that will be available through Tegra Zone. Galaxy on Fire is essentially space trader reimagined for 3D (I remember playing Space Trader an eternity ago on a Palm III) and uses OpenGL ES 2.0 shaders, specular and bump mapping, and 4x higher texture resolution and geometry over the normal version. It’s definitely visually compelling, especially for a mobile device. I’ve played Galaxy on Fire 2 on iOS a little bit and definitely can appreciate the difference in visuals between the two versions.

Dungeon Defenders is sort of a 3D tower defense game with online and RPG components. What makes the title interesting is that it’s Unreal 3 engine based and looks visually compelling.

Accelerometer Gestures

At CES I spoke to a number of people from Kionix, who make MEMS accelerometers for a wide variety of consumer electronics. What they were most exicted about, however, were accelerometers with hardware support for detecting a variety of gestures. Things like detecting where touch events are on the screen purely from accelerometer data (even multiple accelerometers), and gestures such as waving or tapping on all sides of a phone. All that support is baked into the hardware—just watching a register is all that's required on the software side.

They told me to expect to see it in smartphones soon, but I didn't think soon meant this early. When I saw the gestures tab in the 2X, I suspected Kionix. After a bit more digging, I found that the 2X definitely has a Kionix KXTF9 accelerometer inside, and the software support for a number of the gestures I saw demoed, spcifically directional tap and double tap.

Under settings is a field appropriately labeled "gesture" where you can see all the available accelerometer gestures.

Back in the windows mobile days, I remember a number of homebrew applications enabling similar simple things, like putting the phone face down to silence a call or alarm, and rotating the phone clockwise in the air to lock, counterclockwise to unlock. This is sort of the extension of those, except with a few extras and much more polished and accurate detection.

Most of the elements are pretty self explanatory—you can tap on the sides of the phone to move the cursor, go to the next or previous photo, or double tap to change the track. It works surprisingly well. There's also those two gestures I mentioned earlier for silencing an alarm or pausing video and music playback. I show the tap left and right gestures in the overview video, which definitely works well. I think we're at the cusp of finally leveraging the accelerometer in some completely new and exciting ways.

Software Instability

One of the things I’ve been a huge proponent of is actually using every device in for review in place of my own. That was easy with the 2X since it worked with my AT&T SIM perfectly. The Optimus 2X is an excellent device save one huge problem—the software build on it as tested is extremely unstable. To be totally fair, the software LG has running on the 2X right now isn’t what’s shipping in Korea on their version, and isn’t totally final. The first time the instability issues I'm going to mention cropped up, I reset completely to defaults and asked LG and NVIDIA about what was going on.

When I played with the 2X at CES, I had some instability issues, including two random reboots while doing relatively mudane things. The software on our sampled 2X hasn’t randomly restarted, instead, applications crash in the background and go into a force close loop later. There are three main offenders I’ve seen do this on a regular basis, as frequent as once every three to four hours—the browser, messaging, and an LG background process named “omadmclient.” My own speculation is that omadmclient is crashing almost on schedule because it’s an OMA DM client checking for updates at a server that isn’t live yet. That’s forgivable but annoying.

The other two—browser and messaging—are not.

What happens is that periodically, when you try to launch either the browser or messaging, you’ll get a force close loop that doesn’t stop. Killing everything in the background with a task killer doesn’t fix the problem or make the force close loop stop either. A reboot is the only way to get things back up and working. It’s frustrating when that happens to the browser, but an even more serious problem when messaging does it.

When messaging decides to crash, you lose messages. The first time it happened, I assumed my friends were leaving me alone whilst I was working on a four hour long lab assignment. Instead, the entire messaging stack simply died in my pocket, silently. What’s curious is that when this happens, messages are received from the network side but never make it into the messaging database. They completely disappear—the result is that when you pull it out of your pocket to check and experience the force closing, you’ve already permanently lost messages. Another instance that sticks out in my mind was when I was working on this actual article—I assumed friends knew I was busy writing and were consciously making an attempt not to distract. Instead, I ended up losing a couple hours of messages—thankfully most people already are used to me bouncing between devices and periodically discovering things like this.

The other much less urgent thing is a recurring audio "pop" which occurs even muted very now and then when using the phone. It happens at random but just frequently enough to frustrate.

Again, the build of the software on the 2X we tested isn’t final and will definitely change before launch in the US. Nor is this the same software running on the 2X already for sale in South Korea. We pinged NVIDIA and LG about the aformentioned instability issues; NVIDIA confirmed that they saw the same stability issues, but LG told us they haven’t seen or are aware of any crashing or instability. Getting these fixed before launch should be priority one—I’d be using the 2X right now were it not for the constant liability of losing another couple of hours of messages randomly.

 

Camera Analysis: Video Capture HDMI Mirroring and Video Playback
POST A COMMENT

75 Comments

View All Comments

  • GoodRevrnd - Tuesday, February 08, 2011 - link

    TV link would be awesome, but why would you need the phone to bridge the TV and network?? Reply
  • aegisofrime - Monday, February 07, 2011 - link

    May I suggest x264 encoding as a test of the CPU power? There's a version of x264 available for ARM chips, along with NEON optimizations. Should be interesting! Reply
  • Shadowmaster625 - Monday, February 07, 2011 - link

    What is the point in having a high performance video processor when you cannot do the two things that actually make use of it? Those two things are: 1. Watch any movie in your collection without transcoding? (FAIL) 2. Play games. No actual buttons = FAIL. If you think otherwise then you dont actually play games. Just stick with facebook flash trash. Reply
  • TareX - Wednesday, February 09, 2011 - link

    The only reason I'd pay for a dual core phone is smooth flash-enabled web browsing, not gaming. Reply
  • zorxd - Monday, February 07, 2011 - link

    Stock Android has it too. There is also E for EDGE and G for GPRS. Reply
  • Exophase - Monday, February 07, 2011 - link

    Hey Anand/Brian,

    There are some issues I've found with some information in this article:

    1) You mention that Cortex-A8 is available in a multicore configuration. I'm pretty sure there's no such thing; you might be thinking of ARM11MPCore.

    2) The floating point latencies table is just way off for NEON. You can find latencies here:
    http://infocenter.arm.com/help/index.jsp?topic=/co...
    It's the same in Cortex-A9. The table is a little hard to read; you have to look at the result and writeback stages to determine the latency (it's easier to read the A9 version). Here's the breakdown:
    FADD/FSUB/FMUL: 5 cycles
    FMAC: 9 cycles (note that this is because the result of the FMUL pipeline is then threaded through the FADD pipeline)
    The table also implies Cortex-A9 adds divide and sqrt instructions to NEON. In actuality, both support reciprocal approximation instructions in SIMD and full versions in scalar. The approximation instructions have both initial approximation with ~9 bits of precision and Newton Rhapson step instructions. The step instructions function like FMACs and have similar latencies. This kind of begs the question of where the A9 NEON DIV and SQRT numbers came from.

    The other issue I have with these numbers is that it only mentions latency and not throughput. The main issue is that the non-pipelined Cortex-A8 FPU has throughput almost as bad as its latency, while all of the other implementations have single cycle throughput for 2x 64-bit operations. Maybe throughput is what you mean by "minimum latency", however this would imply that Cortex-A9 VFP can't issue every cycle, which isn't the case.

    3) It's obvious from the GLBenchmark 2.0 Pro screenshot that there are some serious color limitations from Tegra 2 (look at the woman's face). This is probably due to using 16-bit. IMG has a major advantage in this area since it renders at full 32-bit (or better) precision internally and can dither the result to 16-bit to the framebuffer, which looks surprisingly similar in quality to non-dithered 32-bit. This makes a 16-bit vs 16-bit framebuffer comparison between the two very unbalanced - it's far more fair to just do both at 32-bit, but it doesn't look like the benchmark has any option for it. Furthermore, Tegra 2 is limited to 16-bit (optionally non-linear) depth buffers, while IMG utilizes 32-bit floating point depth internally. This is always going to be a disadvantage for Tegra 2 and is definitely worth mentioning in any comparison.

    Finally I feel like ranting a little bit about your use of the Android Linpack test. Anyone with a little common sense can tell that a native implementation of Linpack on these devices will yield several dozen times more than 40MFLOPS (should be closer to 1-4 FLOP/CPU cycle). What you see here is a blatant example of Dalvik's extreme inability to perform with floating point code that extends well beyond an inability to perform SIMD vectorization.
    Reply
  • metafor - Monday, February 07, 2011 - link

    According to the developer of Linpack on Android:

    http://www.greenecomputing.com/category/android/

    It is mostly FP64 calculations done on Dalvik. While this may not be the fastest way to go about doing linear algebra, it is a fairly good representation of relative FP64 performance (which only exist in VFP).

    And let's face it, few app developers are going to dig into Android's NDK and write NEON optimized code.
    Reply
  • Exophase - Monday, February 07, 2011 - link

    Then let's ask this instead: who really cares about FP64 performance on a smartphone? I'd also argue that it is not even a good representation of relative FP64 performance since that's being obscured so much by the quality of the JITed code. Hence why you see Scorpion and A9 perform a little over twice as fast as A8 (per-clock) instead of several times faster. VFP is still in-order on Cortex-A9, competent scheduling matters.

    Maybe a lot of developers won't write NEON code on Android, but where it's written it could very well matter. For one thing, in Android itself. And theoretically one day Dalvik could actually be generating NEON competently.. so some synthetic tests of NEON could be a good look at what could be.
    Reply
  • metafor - Monday, February 07, 2011 - link

    Well, few people really :)

    Linpack as it currently exists on Android probably doesn't tell very much at all. But if you're just going to slap together an FP heavy app (pocket scientific computing anyone?) and aren't a professional programmer, this likely represents the result you see.

    I wouldn't mind seeing SpecFP ported natively to Android and running NEON. But alas, we'd need someone to roll up their sleeves and do that.

    I did do a native compile of Linpack using gcc to test on my Evo, though. It's still not SIMD code, of course, but native results using VFP were around the 70-80MFLOPS mark. Of course, it's scheduling for the A8's FPU and not Scorpion's.
    Reply
  • Anand Lal Shimpi - Monday, February 07, 2011 - link

    Thanks for your comment :)

    1) You're very right, I was thinking about the ARM11 - fixed :)

    2) Make that 2 for 2. You're right on the NEON values, I mistakenly grabbed the values from the cycles column and not the result column. The DIV/SQRT columns were also incorrect, I removed them from the article.

    I mentioned the lack of pipelining in the A8 FPU earlier in the article but I reiterated it underneath the table to hammer the point home. I agree that the lack of pipelining is the major reason for the A8's poor FP performance.

    3) Those screenshots were actually taken on IMG hardware. IMG has some pretty serious rendering issues running GLBenchmark 2.0.

    4) I'm not happy with the current state of Android benchmarks - Linpack included. Right now we're simply including everything we can get our hands on, but over the next 24 months I think you'll see us narrow the list and introduce more benchmarks that are representative of real world performance as well as contribute to meaningful architecture analysis.

    Take care,
    Anand
    Reply

Log in

Don't have an account? Sign up now