Related
Hello guys! I need your help and advise.
I need to use my kaiser to work. That's uhh.. receiving calls, making calls, sms, WiFi @ night to sync new contacts to my Google account... you know, small tasks.
I'm using as of yet CM7 with 2.3.32 (#63 IIRC) Data on SD Partition. Now.. although stable (no reboots, no crashes... seems OK) Its painfully slow.
If someone calls me, i have to wait about 7 ringtones before i know who's calling me. So.. i need your advise! Should i use a Donut ? perhaps a 2.6.25 ?
Please be honest, state your opinion and its basis
UPDATE 20110304:
I'm using as of yet:
VaniljEclair RLS11 - A fast & stable CM 5.0.8 for Vogue/Kaiser/Polaris [2010-08-19]
Battery rocks (i'm using a 2.8Ah).
Calls work pefectly.
SMS's work perfectly
Some apps apear to have a .... strange issue. They simply... don't open. But thats temporary. And a reboot fixes.
WiFi works (using latest from liquid with module update).
Quite happy
UPDATE 20110306:
Still no issues. One thing is granted, when i turn the WiFi on and let it sync... bogs down considerably. OC via atools to 490.
Will try the other option now, incubus26c's versions.
UPDATE 20110309:
Using incubus26c's with kernel .25 downloaded and edited through atools.
Been sufering from random phone problems. Simply shutdown. Cannot enable AirPlane mode. Have to reboot.
BTW, anyone has any other sugestions about roms ??
UPDATE 20110310:
Noted that my hardware keyb is sometimes eating letters... notably.. space.
Will check settings to see if disabling something helps.
Try using builds like those by incubus26c's or VaniljEclair. I've had both and enjoyed them greatly, going back to WM for the only reasons of better camera (autofocus never worked on droid for Kaiser) and ad-hoc WiFi support.
And... a few tips.
1. Use phone prioritizer (probably in VanilJEclair). This cuts delay between calling and receiving a call by two times.
2. Odexed firmware is faster, than deodexed. Yeah, no themes anymore, but you want a working device, not a box for bells and whistles, aintcha?
3. 2.6.25 is still up to date. Sometimes you'll need a patch to make wifi work, but that is a reasonable price for better speed.
What about donut? No, it is not faster then any 2.x droids.
StripezZ said:
Try using builds like those by incubus26c's or VaniljEclair. I've had both and enjoyed them greatly, going back to WM for the only reasons of better camera (autofocus never worked on droid for Kaiser) and ad-hoc WiFi support.
And... a few tips.
1. Use phone prioritizer (probably in VanilJEclair). This cuts delay between calling and receiving a call by two times.
2. Odexed firmware is faster, than deodexed. Yeah, no themes anymore, but you want a working device, not a box for bells and whistles, aintcha?
3. 2.6.25 is still up to date. Sometimes you'll need a patch to make wifi work, but that is a reasonable price for better speed.
What about donut? No, it is not faster then any 2.x droids.
Click to expand...
Click to collapse
Clear enough.
Will report back with more info
Thank you
1st Post updated.
And again.
Still no issues. One thing is granted, when i turn the WiFi on and let it sync... bogs down considerably. OC via atools to 490.
1. get RogueTools from Market to overclock the device without atools
2. a question from my side: are Gingerbones worth it?
I actually used and tweaked a Gingerbones. Was quite good, not as fast of course, but then again, more eye candy.
I'm not getting any instability, just plain ... slow during sync. But this as been a standard with any version i've tested.
wifi sync lagging seems to be quite common for all low-end droids, both native and cooked. As long as it happens mostly with encrypted networks, i would suppose the reason is some sort of cryptographic calculations MSM72xx delegates to CPU.
Though, since all unsecured networks I encountered were very slow (256k or so), there's a chance the lag nests in higher bandwidth, causing data to be downloaded a bit too fast to be processed - sometimes HSDPA connection makes the gadget lag, too.
daedric said:
UPDATE 20110310:
Noted that my hardware keyb is sometimes eating letters... notably.. space.
Will check settings to see if disabling something helps.
Click to expand...
Click to collapse
There is strange polling behavior with hardware keyboard on 2.6.25
Though I love stability in 2.6.25 kernel, the Eating of Space button is quiet frustrating when I am texting my boss :| (which I often do) and I press Enter to send right away (just as I am chatting).
StripezZ said:
wifi sync lagging seems to be quite common for all low-end droids, both native and cooked. As long as it happens mostly with encrypted networks, i would suppose the reason is some sort of cryptographic calculations MSM72xx delegates to CPU.
Though, since all unsecured networks I encountered were very slow (256k or so), there's a chance the lag nests in higher bandwidth, causing data to be downloaded a bit too fast to be processed - sometimes HSDPA connection makes the gadget lag, too.
Click to expand...
Click to collapse
So... if the massive slow(ness?? is this a word??) is coming for a bogged CPU on SSL encode/decode, we could... say... use OsMonitor to check?
Which process should be giving lots of CPU usage ?? Android System ?
dark_prince said:
There is strange polling behavior with hardware keyboard on 2.6.25
Though I love stability in 2.6.25 kernel, the Eating of Space button is quiet frustrating when I am texting my boss :| (which I often do) and I press Enter to send right away (just as I am chatting).
Click to expand...
Click to collapse
So... perhaps moving to 2.6.32 should provide me with it a better keyboard polling, at a stability price ??
P.S.
Anyone else would like to suggest another rom ?? BTW... i'm going to try and strip a gingerbones (by Aceyome if i remember his nick right) to gain extra stability.
I think yes. Though I have used .32 kernel for so less time than .25 so as I need the Mass storage functionality, which works perfect with dual mount on .25 kernel. Try Fat Free Froyo by thoughtlesskyle, if you really want a vanilla build
dark_prince said:
I think yes. Though I have used .32 kernel for so less time than .25 so as I need the Mass storage functionality, which works perfect with dual mount on .25 kernel. Try Fat Free Froyo by thoughtlesskyle, if you really want a vanilla build
Click to expand...
Click to collapse
Hey dark_prince, OFF TOPIC question:
How is the Froyo 2.2 x86 ?
daedric said:
Hey dark_prince, OFF TOPIC question:
How is the Froyo 2.2 x86 ?
Click to expand...
Click to collapse
Still not to be used as Primary OS. Alot of things don't work and force close on my D420. Though x86 build works pitch perfect with an EEEPC. It's blazing fast and stripped down to just 80MB and has Hardware OpenGL ES support for intel 915,945,965 chipsets. 1280x800 isnt supported fully as of yet (You can run HDPI one). Market doesnt work, but a proprietary App downloader is provided. Also, keyboard works perfect and mouse emulation is nice. Ethernet + Wifi support depends if kernel supports.
Why doesn't the market work??
(market! y u no work?)
daedric said:
Why doesn't the market work??
(market! y u no work?)
Click to expand...
Click to collapse
It crashes randomly with the build, thats why it was removed. But there is another handy app installer which comes with every x86 build
As I've noticed that most (if not all) Android phones I've ever tried have been suffering from the "non-fluid" issue. The homescreen and apps experience might be fast but they're not fluid like ones found on iOS or Windows Phone and I'm guessing that it's because previous Android phones doesn't have the 2D gpu acceleration. ICS has added the feature and I'd like to ask those owner out there if the experience is now as fluid as iOS or WP7? watching video review doesnt help because videos are formatted into 30fps. Even GS2 doesn't appear to be fluid (aka I dont think it's running at 60fps)
The home screen and app launcher are very fluid if you have a static wallpaper. With a live wallpaper there is considerable slow down. Some wallpapers are less CPU intensive than others though.
Sent from my Galaxy Nexus using XDA App
Android's fluidity is actually due to more than just Hardware acceleration. Most Gingerbread phones come out of the box very quick (Nexus S) and really glide without any apps installed. Hardware [was] acceleration is a big problem, as you were throwing efficiency out the window in order to run on everything. Now with it HW Acceleration, the slickness of the OS has multiplied exponentially giving you an experience on par with iOS (Joshua Topolsky, The Verge)
Now, here comes the real problem, apps. Android apps have the most freedom in the developer sense, and are also the most lax on what is allowed in the market. While iOS dev kit requires a stringent agreement and agreement to an app review process before getting your license, Google's Android Market is nothing like that. If you can pony up $25 (a requirement only recently), you can publish whatever the hell you have made, no matter how ugly, useless, or inefficient it is. Google's toolbox for Devs is great, even greater in terms of options in app making, but enforces no standards or required templates. This is why iOS apps all have the same look and feel while Android's app range from great to complete ****. This makes a lot of sense though as Android started late in the game, so they needed to bring up the app numbers, no matter how many were ugly soundboards or battery hog games.
With ICS, Google is taking a step in the right direction by offering the HOLO hook for developers, which will allow apps to be "prettied up" for ICS instantly. Also, more efficient protocols have been added to keep battery life and smoothness up, such as a revised Garbage Collector (actually, I think they removed it entirely) and allowed apps to share information with each other. The Garbage Collection is what make your phone lag, as it is recycling the unused code on the apps you're running in the background. The new location hook allows apps to now constantly turn on your GPS to pull your location, as they can simply request it from other apps if they don't need the most up-to-date info or if you just recently used your location on another app. The OS should be as fast as any other on the stock level, and as soon as the Apps become ICS friendly and more efficient, Android will truly have people falling in love with it
Chrono_Tata said:
With a live wallpaper there is considerable slow down. Some wallpapers are less CPU intensive than others though.
Click to expand...
Click to collapse
This is particularly annoying. My last Android (Nexus One) was pretty smooth on almost all live wallpapers - certainly on the stock ones. The Galaxy Nexus lags like hell (slow juttery screen swiping) on all of them except one of them. Very, very disappointing and hope it gets fixed somehow.
Live Wallpaper
Thank you everyone, I'm now ordering one for myself and hopefully there won't be a let down on the UI experience!
rikbrown said:
This is particularly annoying. My last Android (Nexus One) was pretty smooth on almost all live wallpapers - certainly on the stock ones. The Galaxy Nexus lags like hell (slow juttery screen swiping) on all of them except one of them. Very, very disappointing and hope it gets fixed somehow.
Click to expand...
Click to collapse
Strange, I owned Nexus One too and live wallpaper (stock one) isn't running at acceptable frame rate at all....it's laggy and sluggish (i changed from iPhone 3G and that might explain why)
May be you can try changing live wallpaper on Galaxy Nexus cuz the one u'r using might not be that optimized?
PS. One more question, how u guys find the battery life?
dnlsmy said:
Also, more efficient protocols have been added to keep battery life and smoothness up, such as a revised Garbage Collector (actually, I think they removed it entirely) and allowed apps to share information with each other.
Click to expand...
Click to collapse
No, they most certainly did not remove the garbage collector but they implemented a more modern algoritm for it and it now makes sure to run on a different CPU core as to not take CPU cycles from the app. A garbage collector is part of the Java platform and could never just be removed since that would result in constant memory leaks that would result in a crash as soon as you filled up all the memory.
When will the stuttering laggy UI experience be addressed?
I'm tired of all the mis-information. There's a pattern: Google is about to release a new handset, they don't show the handset scrolling in any of their ads, or if they do, it's super-imposed. A handful of 'mainstream' bloggers praise the handset calling it quick and responsive and lag free. You buy into it, buy the handset, and the basic UI is anything but CONSISTENTLY fluid and responsive.
I stupidly bought the Galaxy Nexus, really wish I hadn't. Here's just one example of the issue: I have an SMS thread with a mere 27 SMS messages between a friend and myself. When I scroll the up or down the thread, it's embarrassingly choppy (stuttery - don't know what word to use for it). It's extremely unpleasant, and completely ruins the end-user experience.
What annoys me is that Romain Guy closed Android Issue 6914, claiming that it was implemented in ICS. Now ICS is here, and the Android phone is still plagued with the stutters and non-fluidness Android is renowned for. Thankfully someone else has opened a new issue (Android Issue 20278), and hopefully this time Google will FULLY address the issue.
Understandably, it annoys some people more than others. Any user who has experienced a mobile UI that is buttery smooth and fluid (free from 'jitters' and 'stutters'), and where a page or menu sticks to your finger like a magnet when you scroll, would not be able to put up with what Samsung and Google have produced. It's what the kids today would call an 'epic fail'.
---------- Post added at 10:17 PM ---------- Previous post was at 10:11 PM ----------
I'm tired of all the mis-information. There's a pattern: Google around about to release a new handset, they don't show the handset scrolling in any of their ads, or if they do, it's super-imposed. A handful of 'mainstream' bloggers praise the handset calling it quick and responsive and lag free. You buy into it, buy the handset, and the basic UI is anything but CONSISTENTLY fluid and responsive.
I stupidly bought the Galaxy Nexus, really wish I hadn't. Here's just one example of the issue: I have an SMS thread with a mere 27 SMS messages between a friend and myself. When I scroll the up or down the thread, it's embarrassingly choppy (stuttery - don't know what word to use for it). It's extremely unpleasant, and completely ruins the end-user experience.
Understandably, it annoys some people more than others. Any user who has experienced a mobile UI that is buttery smooth and fluid (free from 'jitters' and 'stutters'), and where a page or menu sticks to your finger like a magnet when you scroll, would not be able to put up with what Samsung and Google have produced. It's what the kids today would call an 'epic fail'.
scott.deagan said:
I'm tired of all the mis-information. There's a pattern: Google is about to release a new handset, they don't show the handset scrolling in any of their ads, or if they do, it's super-imposed. A handful of 'mainstream' bloggers praise the handset calling it quick and responsive and lag free. You buy into it, buy the handset, and the basic UI is anything but CONSISTENTLY fluid and responsive.
Click to expand...
Click to collapse
I find this to be untrue, the experience for me has been really good so far. Not perfect but its close. They have come a long way, it'll only get better.
And if you think any of the ads including apple are using true device operation in their advertising you are fooling yourself.
Sent from my Galaxy Nexus using Tapatalk
Can one of you guys post some video footage of said lag? I just ordered a Galaxy Nexus and can still cancel it. Thanks!
Yea there is an iPhone YouTube video performing the exact same steps they show in the commercials and it takes a LOT longer in real life.
Oh well.
G2x - 2.3.7 CM7
Transformer - 3.2 Revolver OC/UV
serialtoon said:
Can one of you guys post some video footage of said lag? I just ordered a Galaxy Nexus and can still cancel it. Thanks!
Click to expand...
Click to collapse
Not something worth canceling your order for, it's barely noticeable.
Nexcellent said:
Not something worth canceling your order for, it's barely noticeable.
Click to expand...
Click to collapse
Its the main reason i left Android. Hoping that one day they will use GPU rendering to assist with UI fluidity. If that is present, its enough for me to cancel an order. Ive been a long time Android enthusiast, but the UI sloppiness is what has kept me from keeping an Android phone for too long.
As a fellow UI lag hater I can tell you it's still there in some places. The problem is, although the base of ICS supports and uses GPU acceleration, 3rd party apps dont yet, and even if you "force" it in the developer settings, it isn't compatible with some apps, and will sometimes cause crashes.
That said, it is ages ahead of Gingerbread, but still not as smooth and fluid as iOS and WP7; not even the GPU accelerated parts.
ICS is a big improvement over gingerbread in terms of fluidity.. but it's not on the same level as iOS and WP 7 yet.
UI lag is one of the things I always hated about Android.. and I feel better about ICS than previous versions.. but they still need to improve it if they want to be on the same level as Apple and Microsoft.
FWIW, I bought the phone having read in several reviews that the phone still suffered (albeit much less) from the usual android-lag. It now compares favorably to iOS and the windows mobile platform, just doesn't match or pass them in fluidity and smoothness.
In my experience, many aspects of the UI are "buttery-smooth" and whatever else reviewers usually say. However, there are still a good amount of moments where lag and hangups are present. The difference is, I'm ok with that. I've accepted the phone for it's plusses, despite it's minuses.
To be clear though, it does lag and hang from time to time. Rebooting once a day helps and I believe forcing GPU rendering under developer settings generally helps.
Sent from my GNex
Dont forget that Andoid does much more in the background and foreground compare to iOS or WP7.
Think multitasking, customization, widgets, etc.
It is understandable Android cannot be as smooth as those iOS and WP7.
And for me, it is more than good enough. I wont ditch Android because it might lag a little bit, because the advantages are much more valuable.
---------- Post added at 11:58 AM ---------- Previous post was at 11:48 AM ----------
Here, this just in ... a thorough explanation from Google Developer about Android graphics:
https://plus.google.com/u/0/105051985738280261832/posts/2FXDCz8x93s
I copied the text here:
How about some Android graphics true facts?
I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:
• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.
• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.
• Android did historically use software to render the contents of each window. For example in a UI like http://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.
• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen. The original Droid however struggled with a similar screen resolution.
• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)
• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice -- there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps.
• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)
• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1024x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.
• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.
Click to expand...
Click to collapse
you saying iOS has no stutter lag..
My iPad stutters all the time. Its no where close to smooth!
Sent from my Galaxy Nexus using Tapatalk
There was some suggestion in this thread that any acceleration is currently software based only, and that the hardware acceleration has yet to be enabled.
I don't know how accurate that is, and there doesn't seem to be a definite answer in that thread.
Perhaps in the 4.1 update?
Evostance said:
you saying iOS has no stutter lag..
My iPad stutters all the time. Its no where close to smooth!
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
+1
Sent from my Galaxy Nexus using xda premium
Hi!
I have great respect for the people that give us our great ROMs, and i KNOW that that is hard - but my question is: why exactly is it that hard?
This is just a question out of curiosity, because I would really like to understand the unerlying problems that cause all the other issues.
I was under the impression that the Android stack runs on top of the Linux kernel.
Usually, the Linux kernel is the Hardware Abstraction Layer, and apps and ROM, in theory, should be kind of hardware agnostic?
e.g. the Bluetooth Issue on our Captivate Glides: I would guess that Android communicates, through some API, with the kernel's BT stack/driver. There must be some (open or closed source) driver available (worst case: some .so module ripped out of an official ROM, maybe?). So why does the headset profile not work? Did the APIs change? Are custom ROMs forced to use another version of the driver?
It also happens to this 50$ chinese tablet i have here: some ROM screw up the touchscreen, some break audio, and so forth. Why can't there be some way of installing a generic ROM, and then side-loading the OEM's drivers?
Thank you again to all ROM developers! This is NO WAY a complaint. Just pure curiosity!
I may be out of my league when trying to describe this, but the processor in our phones is somewhat different to the processor in the bulk of other phones. This is where majority of the issues came from in porting ICS to the glide before ATT released it. Even after the first official ICS update, the modders here were the ones who fixed the keyboard lights... I changed up to JB because the GPS wasn't locking quick enough and PACROM had all the quick toggles and the speed/gps lock I needed.
Sure the kernel is the underlying part that pulls it all together, even still there is all the drivers that need to work with it. If there isn't a bluetooth/wifi/HW Video driver for the version of the kernel, then it gets really tricky and now its coding for a piece of software to speak with the hardware ..... We have things that partially work, but not fully ...as with everything computers, in theory things that "should" work, don't always... I'm an IT tech.. I run into weird **** all the time that "should" work ... takes time, but with persistence and the right skillset, majority of the time a resolution can always be found.
A problem I always had with the Xperia S is that the whole thing feels extremely choppy and clunky. I have extremely low tolerance for choppyness, and this phone has always felt really clunky for me, it's hard to pretend the choppyness isn't there. There is nothing that makes me feel good about a device than silky smoothness, and even though the phone is still very fast and reactive, the slow framerate and microstutters are extremely noticeable, especially if you ever used a smooth device before (such as my good old Xperia Ray on gingerbread which was smooth like an iPhone, and when I upgraded it to ICS I couldn't stand it anymore because it became horrendously stuttery).
I was wondering, since Project Butter promises fully accelerated UI and elimination of the persistent lag that all android phones have, do you think this will finally resolve the slugginess of this phone's stock rom?
Is PB an OS features that all phones running JB have, or do the developers (in this case Sony's) have to implement it on their own?
Also, regarding the current stock ICS, there is nothing that helped with the constant lag and choppyness in the UI, the only thing that DOES make a difference is enabling "force GPU rendering", it's found under "developer options" and disabled by default. Once you enable it, scrolling lists (such as the settings menu) will become silky smooth (you have to go back to home and then back to settings menu to notice the difference). With this disabled, scrolling every list menu is embarassingly choppy. It doesn't cause any battery drain so I recommend everyone to enable it if you haven't already.
I seriously hope JB will resolve the constant choppyness of this phone's UI.
MarkMRL said:
A problem I always had with the Xperia S is that the whole thing feels extremely choppy and clunky. I have extremely low tolerance for choppyness, and this phone has always felt really clunky for me, it's hard to pretend the choppyness isn't there. There is nothing that makes me feel good about a device than silky smoothness, and even though the phone is still very fast and reactive, the slow framerate and microstutters are extremely noticeable, especially if you ever used a smooth device before (such as my good old Xperia Ray on gingerbread which was smooth like an iPhone, and when I upgraded it to ICS I couldn't stand it anymore because it became horrendously stuttery).
I was wondering, since Project Butter promises fully accelerated UI and elimination of the persistent lag that all android phones have, do you think this will finally resolve the slugginess of this phone's stock rom?
Is PB an OS features that all phones running JB have, or do the developers (in this case Sony's) have to implement it on their own?
Also, regarding the current stock ICS, there is nothing that helped with the constant lag and choppyness in the UI, the only thing that DOES make a difference is enabling "force GPU rendering", it's found under "developer options" and disabled by default. Once you enable it, scrolling lists (such as the settings menu) will become silky smooth (you have to go back to home and then back to settings menu to notice the difference). With this disabled, scrolling every list menu is embarassingly choppy. It doesn't cause any battery drain so I recommend everyone to enable it if you haven't already.
I seriously hope JB will resolve the constant choppyness of this phone's UI.
Click to expand...
Click to collapse
If you're really curious you could flash the test version DoomlorD posted. There's also this video on Youtube:
http://www.youtube.com/watch?v=kNLODO3YOnA
Looks like it is more fluent, as was expected, but ofcourse that's a nearly empty firmware. Some 3rd party apps can make your phone a lot slower, even when they're supposedly not running. A clean installation of ICS is also quite fluent compared to the lags I've had caused by some apps before I removed or restricted them.
Redstarr1 said:
If you're really curious you could flash the test version DoomlorD posted. There's also this video on Youtube:
http://www.youtube.com/watch?v=kNLODO3YOnA
Looks like it is more fluent, as was expected, but ofcourse that's a nearly empty firmware. Some 3rd party apps can make your phone a lot slower, even when they're supposedly not running. A clean installation of ICS is also quite fluent compared to the lags I've had caused by some apps before I removed or restricted them.
Click to expand...
Click to collapse
I can't flash it because I'm not unlocking my BL. Also, which apps do you think are the most resource hungry? I already disabled facebook and all social network related stuff, most services like sony select, etc. No difference at all.
My Xperia S and my Nexus 4 feel as smooth as each other using go launcher and obviously one has project butter and one doesn't
A simple solution would be to set a background process limit to 3 or less (developer options-resets on reboot so take care of that)
Also decrease the transition and animation from 1 to .5(dev options again)
If u are rooted(which am expecting u are)
Use romtoolbox or any utility capable of profiling ur cpu...set two profiles..screen off->governer-ondemand-low frequency(will save battery)
And one as screen on->governer-performance-max frequency(reduce ur lag)
If u have too many apps..use greenify or some app with same functionality
These basic settings have kept my ion lagfree all the while
Sent from my Xperia ion
Hit a thanks when someone helps
for what it's worth, i just came to the xperia S from the original galaxy S. i was running JB on that, which has nowhere near the specs of the xperia S, and JB was smooth as silk there, so it does seem to make a noticeable difference. moreso on 4.2 than 4.1, however.
unfortunately i've been hit with the bootloader unlock = no , so the wait for jb again begins..
MarkMRL said:
I can't flash it because I'm not unlocking my BL. Also, which apps do you think are the most resource hungry? I already disabled facebook and all social network related stuff, most services like sony select, etc. No difference at all.
Click to expand...
Click to collapse
That's why I posted the link to the Youtube video so you could get a glimpse that way .
I'd also disable Google+ and Google Talk if you're not using those. And some apps that you installed yourself from the Play Store can make your phone sluggish as well. I used Greenify to force my games and some apps to hibernate (Angry Birds, Dropbox, Google Drive etc), saved over 100mb in available memory. That has made my phone a lot less laggy. I usually don't encourage using app killers but Greenify is doing a good job with no errors for the past 3 days.
absolutely yes
jb leaked is the smoothest thing i have ever seen
Hi,
I'm on the Tmobile H811 G4.
I have a rooted custom rom, and i've debloated most of my non-essential apps by freezing them via Titanium backup. I also use a custom launcher, (Action Launcher) which doesn't lag at all. Generally I don't have any lag issues. However, it's only on the lockscreen. B/c of work requirements, I have to use the PIN security login, and when I tap the buttons for the PIN, it lags. I'm talking maybe a 1/3 of a second, but strangely for the last 3 or 4 digits (out of the 6) that I'm using. There's a lag also when I press the OK button.
It doesn't happen all the time, just once in awhile.
I used to use a oneplus one with CM12.1 and compared to that fast, smooth lockscreen login, there's definitely a noticeable lag.
Btw, I do also have the force GPU rendering on as well.
Is anyone else experiencing this? If you have in the past, and resolved it, any tips?
Other than this, I really like the G4. I've tweaked it also with the G4 tweaks, and overall it runs well.
Thanks in advance.
I'm seeing the same lockscreen lag. Seems insane that entering four digits should produce such stutter.
Not really seeing any lag or stutter elsewhere (on Google Now launcher), except perhaps ad-intensive pages in Chrome, but that's true of most phones. Oh, and when I use tap to wake (whatever it's called), I double tap once, nothing happens, double-tap another time, and presto it wakes up. Every time, the first attempt fails.
Overall my stock N5 seems a bit snappier, but no real complaints with the G4.
Mostly I just miss the perfect size of the N5.
I too am experiencing the same issue. Seems that I can finish typing a full sentence on the keyboard before I can enter 4 digit pin! I do not get it this phone has 3 gigs of ram and it still lags.
alextop30 said:
I too am experiencing the same issue. Seems that I can finish typing a full sentence on the keyboard before I can enter 4 digit pin! I do not get it this phone has 3 gigs of ram and it still lags.
Click to expand...
Click to collapse
You can have 32 GIgs of RAM, if the software which handles the operations has flaws. This issue is caused by LG's software mods most likely the launcher.
davebugyi said:
You can have 32 GIgs of RAM, if the software which handles the operations has flaws. This issue is caused by LG's software mods most likely the launcher.
Click to expand...
Click to collapse
You are right, I should know this as a software developer! It is funny when I call LG about my issues they tell me that there are no known issues with the phone (lag and missed taps being the most prevalent). They also will not acknowledge that their software is crap, this is why vanilla android is better - I think I trust Google developers a bit more than LG - which I have come to the realization that the only thing I will trust them with is to make my next TV.
alextop30 said:
You are right, I should know this as a software developer! It is funny when I call LG about my issues they tell me that there are no known issues with the phone (lag and missed taps being the most prevalent). They also will not acknowledge that their software is crap, this is why vanilla android is better - I think I trust Google developers a bit more than LG - which I have come to the realization that the only thing I will trust them with is to make my next TV.
Click to expand...
Click to collapse
Missing taps are because of the touchscreen firmware is buggy, which is mostly noticeable on the JDI panels, rather than the own LGD (yep, LG using two different display manufacturers - which is very common by every OEM nowadays, some even use 3). That said, having a LG's own display panel with the latest firmware I never had a single missing tap.
On the other hand, if you want unique features in your software, you have to pay the price. Still, Samsung is worse at it than LG (that's why I changed from a S6 - 920F).
But back to the topic - I stopped experiencing the lag (and operation lags in general), once I switched to my all-time favorite Nova Launcher Prime. LG's default launcher is great in terms of functions (more functions than Touchwiz and Sense Launcher IMO), but had re-draws and lags here and there probably because of the poor code.
They can ship without a default launcher TBH, since I always change to Nova in the end (Also did on my HTC M7, Z3compact, Oneplus One, S6).
However, this still does not change the fact that LG needs to improve a bit on their debugging and performance optimization.