Link to Source
......
• 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.
• "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.) .....
Click to expand...
Click to collapse
The link above goes covers more bullet points on the issue. If you're interested click it and read
duplicate thread
http://forum.xda-developers.com/showthread.php?t=1377519
has anyone ever bothered to go into developer options in settings and turn off transition animations scale or windows animation? to see if things are speeded up even more so. I noticed with windows animation off, the setting screens just pop onto the screen vs. a more gradual appearance of it. I'm trying it with those off to see if any noticeable increase in UI speed. although my UI was fast n lag free before, I'm just curious to see if speed increased even more. Someone brought up a point before that one reason IOS UI is fast because they don't have fancy transition animations n such like android. so cutting those off "should" theoretically improve ICS UI.
I just use the app "spare parts" to speed up the window and transition animations.
krispy521 said:
I just use the app "spare parts" to speed up the window and transition animations.
Click to expand...
Click to collapse
I have that app also. but instead of just speeding them up, you can completely shut them off. things do move alot faster as far as ui goes. if you put the transitions to 10x you get this cool slow mo fading effect when switching to certain tasks or apps. but going into developer options and cutting off windows animation and transition animation does speed things up. they pop on the screen that much faster.
I might try out the spare parts thing to see how that fares. reminds me of an app I had on Ipad, jailbreak needed, that was like a fake gpu accelerator. all it did was speed up window animation and transition animation. it worked well so ill take a look at this. I'd still think completely shutting them off is the fastest method vs. speeding them up.
edit update: I just tried out spare parts like you said. Do you know what speeding up the windows n transitions animations really does in that app? lol all it does is change the developer animation settings. I compared it. OK for example stock developer settings has windows and transition set at 1X by default. now if you go into spare parts app and put those animations to fast, all it did was change developer options animations to .5x speed. so really that spare parts app is not even needed for that. you can go straight into developer options and change this without needing that app. I did it a few times and looked back n forth at spare parts settings then developer options and all it does is change developer option speed. which I can do within Asus settings itself. even in the app description it says cutting them off brings fastest device performance.
I still wish we could find out a more technical answer on if Forcing GPU rendering helps or not. and if it does, is there extra battery drain? only seen mixed answers. nothing concrete yet. I have noticed in the developers section there's a custom rom calles WSG rom. one of his features is that he basically cut off CPU rendering and forced GPU rendering full-time. been hearing good things about how fast it is. I wonder if its the same as going into developer options and forcing gpu rendering. Anyone has any technical insight into this?
I think I was the one who mentioned the screen transition in a thread where someone was calling the TFP laggy.
I have mine set to none. I don't see why anybody would use screen transitions. Isn't instant screen changes what everyone wants?
theandies said:
I think I was the one who mentioned the screen transition in a thread where someone was calling the TFP laggy.
I have mine set to none. I don't see why anybody would use screen transitions. Isn't instant screen changes what everyone wants?
Click to expand...
Click to collapse
cutting off those animations does bring instant screen changes. I think I will leave them off. UI is even faster than before with them off. everything, as far as UI. launching apps, etc..is instant.
here is technical info on what happens when you Force GPU rendering. I asked the developer MasterZen about it in his thread. He isbthe Creator of WSG Rom, where he added the feature of removing software(CPU) rendering and forcing GPU rendering full-time. here's his quote:
" FULL GPU rendering puts our tablets into a state where all the rendering steps, both rasterization and scene composition, are handled by the GPU. The rasterization step in the rendering phase takes all the display list objects, either vectors and bitmaps, and creates textures to be rendered. Then the textures are copied on to the buffer. Thus freeing up our CPU for more excessive task"
demandarin said:
here is technical info on what happens when you Force GPU rendering. I asked the developer MasterZen about it in his thread. He isbthe Creator of WSG Rom, where he added the feature of removing software(CPU) rendering and forcing GPU rendering full-time. here's his quote:
" FULL GPU rendering puts our tablets into a state where all the rendering steps, both rasterization and scene composition, are handled by the GPU. The rasterization step in the rendering phase takes all the display list objects, either vectors and bitmaps, and creates textures to be rendered. Then the textures are copied on to the buffer. Thus freeing up our CPU for more excessive task"
Click to expand...
Click to collapse
Is this how iOS does it? Are there any drawbacks to full GPU rendering, more crashes..ect?
demandarin said:
here is technical info on what happens when you Force GPU rendering. I asked the developer MasterZen about it in his thread. He isbthe Creator of WSG Rom, where he added the feature of removing software(CPU) rendering and forcing GPU rendering full-time. here's his quote:
" FULL GPU rendering puts our tablets into a state where all the rendering steps, both rasterization and scene composition, are handled by the GPU. The rasterization step in the rendering phase takes all the display list objects, either vectors and bitmaps, and creates textures to be rendered. Then the textures are copied on to the buffer. Thus freeing up our CPU for more excessive task"
Click to expand...
Click to collapse
That's how apple does it! I am telling you guys why do you think they use extensive amounts of VRAM and also why they leave their CPU clocked so god damn low!
We should start forcing that in all roms and send a letter to Andy Rubin if we find it helps a bunch!
Sent from my PG86100 using Tapatalk
aypanthony said:
Is this how iOS does it? Are there any drawbacks to full GPU rendering, more crashes..ect?
Click to expand...
Click to collapse
I'm not noticing any drawbacks at the moment on full gpu rendering. MasterZen said in his thread that he will put together a beta team to see if it has any drawbacks or improvements to battery performance.
Wordlywisewiz said:
That's how apple does it! I am telling you guys why do you think they use extensive amounts of VRAM and also why they leave their CPU clocked so god damn low!
We should start forcing that in all roms and send a letter to Andy Rubin if we find it helps a bunch!
Sent from my PG86100 using Tapatalk
Click to expand...
Click to collapse
good idea. plus people should definitely go into developer options and cut off the windows and transition animations, tablet is Wahhabi more snappier now. add force gpu rendering and UI n everything becomes really fast. mines was already great before but cutting off those animations took it to another level. I'm forcing gpu rendering also to see how that fares also. we might be on to something
Wow... i just changed the Windows and transition animation setting to 0.5 instead of 1.0 and enabled the force gpu option. There is a Noticeable improvement in GUI speed for the interface. I like the eye candy so didn't want to completely turn them off.
Thanks for the tip!
Def a speed boost when turning off animations.
MadmanJay said:
Wow... i just changed the Windows and transition animation setting to 0.5 instead of 1.0 and enabled the force gpu option. There is a Noticeable improvement in GUI speed for the interface. I like the eye candy so didn't want to completely turn them off.
Thanks for the tip!
Click to expand...
Click to collapse
no problem
demandarin said:
good idea. plus people should definitely go into developer options and cut off the windows and transition animations, tablet is Wahhabi more snappier now. add force gpu rendering and UI n everything becomes really fast. mines was already great before but cutting off those animations took it to another level. I'm forcing gpu rendering also to see how that fares also. we might be on to something
Click to expand...
Click to collapse
Benchmark it like that!
Sent from my PG86100 using Tapatalk
Wordlywisewiz said:
Benchmark it like that!
Sent from my PG86100 using Tapatalk
Click to expand...
Click to collapse
OK. ill do it tonight. I doubt the animations would affect anything but forcing GPU rendering could have dramatic effect for the positive in the benchmarks. as far as gpu side of things goes.
Hi all, I would like to have opinion from you guys.
Under Development Settings, There Is a Force GPU rendering option
Force GPU Rendering []
Use 2D hardware acceleration in applications
Is it good to enable it or not ?
Some of my friends say Yes, some say No.
Well, I would like to have opinion from you guys now
YeoZy96 said:
Hi all, I would like to have opinion from you guys.
Under Development Settings, There Is a Force GPU rendering option
Force GPU Rendering []
Use 2D hardware acceleration in applications
Is it good to enable it or not ?
Some of my friends say Yes, some say No.
Well, I would like to have opinion from you guys now
Click to expand...
Click to collapse
Graphics are handled in one of two ways, "software", which means the primary CPU does the heavy lifting, and "hardware" which means the GPU does the lifting. Hardware rendering is better because it frees up CPU clock cycles for other stuff, so the phone moves faster/smoother (plus GPUs are designed to excel at the types of calculations graphic intensive applications do). This feature supposedly forces programs to use the GPU to paint 2D objects on the screen (2D was previously unsupported, so most apps and the base UI were software accelerated, 3D should be hardware by default), but it can cause crashing, bugginess.
Devs have the option to enable hardware acceleration with a simple line of code (according to Google at least.) If they choose to enable it, the app will be hardware accelerated regardless of what you set in there.
source-http://pocketnow.com/2012/05/25/what-is-force-gpu-rendering-in-ice-cream-sandwich/
Thanks for your info, mate
So that's why some app behaves weirdly, right?
My camera behaves weirdly. And the black background of apps tends to have a white gradient from bottom up.
so, you enable it or not?
Your Sound Mod rocks too, waiting for Clear Audio+
YeoZy96 said:
Thanks for your info, mate
So that's why some app behaves weirdly, right?
My camera behaves weirdly. And the black background of apps tends to have a white gradient from bottom up.
so, you enable it or not?
Your Sound Mod rocks too, waiting for Clear Audio+
Click to expand...
Click to collapse
No mate I dont have those problems
Yeah i enabled it
Are you using Chainfire3D?
You can try to compare and contrast with GPU rendering on and off.
Eg the back ground of root explorer. There will be LIGHT WHITE GRADIENT from bottom up.
No, I'm not using ChainFire3D. But I've tried it before. It ruins my graphics, games don't function properly even.
#Using STOCK 431 fw
YeoZy96 said:
You can try to compare and contrast with GPU rendering on and off.
Eg the back ground of root explorer. There will be LIGHT WHITE GRADIENT from bottom up.
No, I'm not using ChainFire3D. But I've tried it before. It ruins my graphics, games don't function properly even.
#Using STOCK 431 fw
Click to expand...
Click to collapse
YOU HAVE TO INSTALL PLUGINS FOR THAT
You can run tegra games on ray
Yeah, I know. But it still don't function properly. Sheesh...
I only use it while I'm gb where everything works fine.
Mate, spare our poor Qualcomm S2...
Playin Tegra games on ray it's like pushing it to the limit ouch
If it's Qualcomm S4 with Dual Core 1.5GHz Krait Processor. You're good to go
Hi there,
GyroscopeNoiseFilter (previously: JitteryGyroFixForCardboard) is a module to reduce/eliminate the noise in unstable gyroscope that are found in some phones like the Moto G 2nd gen or Huawei Ascend G7. Basically, the app does the noise smoothing that app devs do, but here this module uses a system hook to apply the noise smoothing preprocessing for all apps, but the main goal here is specifically to remove jitter, not drift (although the filters may help, but there's no sensor fusion, yet).
This is particularly interesting for virtual reality (VR) or head-tracking apps because a noisy gyroscope will produce a feeling of dizzyness and nausea, but this can also be interesting for any app using the gyroscope because the output will be a lot smoother and accurate (particularly when the phone is held still).
The module was originally wrote by Kjos and the repo lives here:
https://github.com/Kjos/XposedJitteryGyroFix
The thread that started the module is on Reddit:
https://www.reddit.com/r/GoogleCardboard/comments/335ins/fix_for_jittery_gyroscopes_such_as_moto_g
Here is the latest version of the module, v1.4 (also attached to this thread):
https://github.com/lrq3000/XposedJitteryGyroFix/releases/download/v1.4/GyroscopeNoiseFilter_v1.4.apk
The module is also available directly from the Xposed repo:
http://repo.xposed.info/module/net.kajos.gyronoisefilter
=== DESCRIPTION ===
The gyroscope is the main sensor for head tracking / virtual reality apps.
However, it's common for phones' gyroscopes to be noisy, which in practice shows as jitter, and this can create a dizzyness feeling and nausea, particularly when standing still (the "camera" still moves around just like if you were at sea).
Android now offers "virtual" sensors, which use a method known as sensor fusion to avoid those noisy outputs by combining several sensors (usually: gyroscope, accelerometer, magnetometer).
However, it's up to each app dev to use these virtual sensors, and to implement further post-processing to smooth the sensor and reduce the noise.
This module adopts another approach: it hooks directly to the hardware gyroscope and it preprocess every outputs with smoothing filters before relaying the data to the apps.
Therefore, the noise is reduced or even eliminated of the gyroscope's output for every apps.
=== OPTIONS ===
This module currently implements a few different strategies to filter and reduce noise, which can be used complementary or alone (each option can be disabled):
1. Filter type: type of the filter that will be applied to reduce noise in the gyroscope output.
2. Filter size: the number of samples to use to compute the filtering. Usually, the bigger the filter is, the less jitter there will be but at the expense of some lag.
3. Filter optional value: value of the constant that configures some types of filters such as lowpass or additive smoothing.
4. Minimum value change threshold: prevents the phone from registering the new sensor's values if the difference to the median is smaller than the given threshold.
5. Stationary minimum value threshold: when stationary, prevents the sensor from moving if the change is below the given threshold (this is similar to min value change but here it only affects the stationary state, when you are not moving).
6. Rounding precision: round all sensor's values to the given decimal.
Options can be changed on-the-fly without having to restart the phone, and are instantly applied to the sensor, so that you can switch between this option screen and a VR app to test for the parameters that reduce the jitter the most for you.
Click to expand...
Click to collapse
I'm looking for feedback before we submit to the Xposed repo, so if you have any idea of a feature or if you spot a bug, feel free.
We are also looking for better filters, currently the best performing two types are the median filter and the one order low-pass filter, so if there's someone with some experience with noise reduction on the gyroscope (not the accelerometer), I'd be very interested to get some advices about that!
/EDIT: update v1.4.
Also, we found a great opensource app called GyroscopeExplorer (kudos to the dev) which implements all kinds of sensor fusion and with a very good documentation, so that's a great source of info to implement advanced filters, but, although they smooth the movement's noise and drifting issues, they do not fix jitter at all, so for the moment we won't implement these advanced filters. We are now focusing on supporting more apps, particularly the ones using the new Cardboard NDK API to access virtual sensors (this bypasses the usual SensorManager).
Sorry, I forgot to attach the APK directly to the thread, like it's usually done around here. That's now done.
Very interesting module.
I wonder if this would give better results when doing Photospheres with the Google Camera app.
Also, does this have any meaningful impact on cpu usage and battery draining ?
thanks!
edgrd said:
Very interesting module.
I wonder if this would give better results when doing Photospheres with the Google Camera app.
Also, does this have any meaningful impact on cpu usage and battery draining ?
thanks!
Click to expand...
Click to collapse
I never made Photospheres with the Google Camera app, but if it uses the Gyroscope and you experience some jitter, then the module should help yes.
About CPU, the module is quite light on resources. The exact usage mostly depends on the filter type and filter size, with the low-pass filter being the lightest on CPU (only a few additions and multiplications, so it's negligible). All the other options such as the "minimum value change" only do a single calculation so their CPU usage is also negligible. However, if you use the mean or median filters and with a big filter size (like 1000), you may notice a very very small CPU usage, but it will still be very low (the time of a summation over an array of the size you specified, so it's not that big).
I have experienced some small (but still perceived) input lag using the default filter (median), switching to the lightest one and decreasing filter size to 8 fixed it
Would be nice if this module was presented more as an improvement / upgrade to the default gyroscope output, other than a simple fix
And after the app matures a little bit, you could make it available on the Play store too, so more people get this benefit
thanks again :good:
Good idea, but I can’t make head or tail of it. Maybe you ought to include simple preset/config… (sophisticated, uniform, simple & powerful, extreme…etc.), so that punters with Cardboards don’t spend a week scratching their heads on figuring out values, stationary thresholds and precisions.
I get nauseous using both DK2 and smartphone HMDs - don’t know if it’s me or noisy gyroscopes.
Thank's for the feedback everyone
@edgrd: yes the median filter smoothes the gyroscope more but it adds a delay proportionally to the filter's size. The low-pass filter does not add any perceptible delay, and the filter size does not matter (it only uses the previous gyroscope's value, so the filter size is always 1. I have yet to find the calculation for a bigger low-pass filter - but it works already very well as it is).
Indeed this is more an improvement now than a fix, that's why we renamed the app now to GyroscopeNoiseFilter
@Lord Childe: thank's for the idea of presets, I thought about that but however I can't think of a way to provide presets, since the values you set entirely depends on your own gyroscope's values. So for the moment, it is advised to just try out different values and you can switch back and forth to a VR app of your choice to instantly see the effect. Maybe we could do some kind of automatic calibration (eg, don't move your smartphone for a few seconds and this will automatically detect the values of the jitter).
Personally, on my Huawei Ascend G7, I use the low-pass filter and the stationary minimum value change set at 0.2. All the others are at default. And yes, this helps greatly to reduce the nausea for me (because when the phone still moves while you are standing still, this produces a feeling similar to being sea-sick).
Does not work on Cyanogenmod 12.1 Moto G 2nd Gen
Hi folks,
Tried to get it working on my Moto G 2nd Gen running Cyanogenmod 12.1. I can set the values but the Google Cardboard app does not seem to be taking the filtered values.
I tried running the Gyroscope Explorer app and if I enable Mean Smoothing, the app (Gyroscope Explorer) shows smooth values. But still has no effect on the cardboard app.
arindammanidas said:
Tried to get it working on my Moto G 2nd Gen running Cyanogenmod 12.1. I can set the values but the Google Cardboard app does not seem to be taking the filtered values.
Click to expand...
Click to collapse
Yes indeed, this is the issue we are currently working on. It seems that there are currently two ways to get the head's position: using SensorManager/SystemSensorManager, or using the Cardboard SDK's own method. The latter seems to completely bypass the SensorManager, which is the usual way of accessing the gyroscope's values. Most cardboard's apps are still using the SensorManager to access the gyroscope, so for these apps, our module works correctly. But for newer cardboard's apps using the Cardboard SDK orientation provider, our module does not work.
This is a pretty tough problem, and I never developped a Cardboard's app. If someone with experience with developping a Cardboard app can give some help with some advices, this would really help us a lot!
We just updated the module, Arindammanidas. Please try the latest version (v1.5) and see if this fixes your issue:
http://repo.xposed.info/module/net.kajos.gyronoisefilter
https://github.com/lrq3000/XposedJitteryGyroFix/releases/tag/v1.5
If it doesn't fix your issue, please tell us what app and what version doesn't work with our module. We are aware that there are still a few apps that may not work, in particular Cmoar Cinema Pro v4.3 (but version Free is OK). We don't yet know why (the source is closed).
/EDIT: we narrowed down the issue, and it seems that only apps using Unity3d along with the Durovis Dive SDK for head tracking are not supported. It seems it's because they use their own native library to manipulate the sensors, so I'm not sure we can do anything about these apps...
I just uninstalled Xposed! I'll flash it back and report! Thanks a lot.
lrq3000 said:
We just updated the module, Arindammanidas. Please try the latest version (v1.5) and see if this fixes your issue:
http://repo.xposed.info/module/net.kajos.gyronoisefilter
https://github.com/lrq3000/XposedJitteryGyroFix/releases/tag/v1.5
If it doesn't fix your issue, please tell us what app and what version doesn't work with our module. We are aware that there are still a few apps that may not work, in particular Cmoar Cinema Pro v4.3 (but version Free is OK). We don't yet know why (the source is closed).
Click to expand...
Click to collapse
Hi, I tried out version 1.5 and it still gives me jitters in the google cardboard app demos. Probably the cardboard app is reading from somewhere else?
Which google cardboard app? Do you mean the treasurehunt? Normally, treasurehunt is supported. Is it another app you are talking about?
lrq3000 said:
Which google cardboard app? Do you mean the treasurehunt? Normally, treasurehunt is supported. Is it another app you are talking about?
Click to expand...
Click to collapse
I was talking about the demos on the cardboard app itself. When you open the Google Cardboard app, you have an option for some demos e.g. Windy Day, Google Earth etc.
These still have jitters.
You're correct, I totally forgot about those demo apps and I didn't try them. We will see what we can do. Thank you for the feedback.
Is there any way to reduce drift when using photosphere or taking panorama photographs in Google camera?
Hello, I have a 'lenovo k3 note "with android 5.0.1, this phone has no physical gyroscope, makes a software simulation using other sensors.
I've been playing some value to your program and seems to improve a bit, but keeps moving image when this stop.
I can change the way you treat the sensor data? Even without one hardware.
Moto G 2014
For those with a Moto G 2nd generation, what are your settings?
Dear developers.
Is it possible to put an inversion of some of the axes in this module?
Some Chinese smartphones (for example ZOPO ZP998, iOcean x8), the gyroscope's axis is inverted, and the manufacturer ignores requests to fix it.
AKSU78 said:
Dear developers.
Is it possible to put an inversion of some of the axes in this module?
Some Chinese smartphones (for example ZOPO ZP998, iOcean x8), the gyroscope's axis is inverted, and the manufacturer ignores requests to fix it.
Click to expand...
Click to collapse
Wow, I was about to post the same because I was impressed someone managed to change gyroscope values. Yes, I have the same problem, my spanish smartphone comes with the X axis inverted, so the sensor fusion makes strange things (gyroscope and magnetometer/accelerometer read oppossite values), although I think this could be another app instead of adding it to your noise filter one (because in my phone there's no jittery, only a changed axis. It could be solved by the developers, but at this time there's no patch).
Thanks a lot!