Related
I would like to hack in to two andorid devices, mic and the GPS device. With the mic I want to get the back ground noise. Measure the intensity of sound for ex - lets say frequency or some dB value (which ever is supported). With GPS obviously the location cordinates.
On the android platform it will be easy to do this as an application. However I want to pass this data to the kernel..how to achieve that? a user space daemon polling the above sensors constantly(then agian how to write to the kernel space..), or can I get these values in the kernel space itself? (ex- as a bite stream from the device driver)
Appreciate any ideas about the matter..
I think the os can do realtime calculations. But kernal????, as of my knowledge kernal is a bridge that connects the hardware with the software( os here) and dnt think that kernal itself can do calculations, but kernal can adjust the o/p , i/p parameters to the os( for eg. Android kernal parameters can be adjusted by init.d or local.prop scripts. ) . But they are executed in os startup, and i think they are constant through out the operating time or untill next boot. So i think either of these scripts can be used to adjust some thing, but not in real time but in each boot.
So the idea is read the values via some app, use the app to generate the script with desired value, inject it to the system folder, and it will be executed on next startup.
Still i dont get the point, why do u want the kernal itself to do the things.
HD2 HYPERDROID EXTREME EDITION V6.0.1 @ FIKERT KERNAL.
I'm not sure why you're so big on doing this in kernel.
GPS data is so slow that you could easily handle it on a TRS-80.
Audio data is not a heap of work either.
Ok, I would write any heavy computations in a native lib (in user space).
I'm not sure if Android phones (versus other Android devices) use ALSA,
but I've written my own code for interfacing with ALSA directly and bypassing Android.
Hi, I've been looking at running GNU Linux apps on a rooted android. device with modern hardware and I've yet to find a 'nice' way to run x apps with acceptable GUI performance. Currently I've tried the java implemention of x on android which is barely useable and various vnc - rpc intergrations running x11 using a virtual frame buffer which is much better but laggy.
My idea to solve this problem is to completely do away with the vnc etc.. proxying. that 8s hack the virtual frame buffer version of xorg so that the main pixel map surface is in ipc shared memory and use ipc to render this through the android api.
So is it possible to statically link the needed android libraries to allow abdroids ipc to work between a hacked xorg vfb and abdroids shared memory ipc to a native android app. Thus making high performance rendering with near zero memory coppies possible.
Secondly, and this would be a bonus, could I even get rid of ipc and a native android app by getting xorg on my root GNU Linux install to work directly with android graphics and UI apis. This would be ammazing.
Hopefully ipc is at a kernel level so it may be possible to just port the needed parts of android to GNU Linux to do this if the statically linking method is known not to work.
Any ideas and suggestions, what do you think of this idea for intergraring GNU Linux x apps and android.
I really like this idea and I've been looking for something like this. You said you used the "X server" android app? I'm kind of curious on the performance. Was it laggy or just that it wasn't fully what you expected?
jthree2001 said:
I really like this idea and I've been looking for something like this. You said you used the "X server" android app? I'm kind of curious on the performance. Was it laggy or just that it wasn't fully what you expected?
Click to expand...
Click to collapse
Currently I'm running xrdp and tightvncserver in a gnu/linux environment (using inode linking not chroot) and xfe as the windows manager.
I connect to this from android using a rdp client.
The main issues appear to be very slow performance on graphics updates, visably slow, which I put down to the overheards of running everything through vnc/rdp - over sockets - mem coppies, compression (which I should turn off to see if it helps) encryption and all that stuff that goes along with rdp and vnc that's not needed if you use something like shared memory and blit to that.
Performanc of the apps in xfe &co, for instance libraoffice or eclipse etc.... seems to be pretty good, so that's not the issue, just the graphics.
Running a Asus transformer infinity T700
my current messing arpund has been trying to get the Android NDK to compile and run on ARM, which in theory should be no problem so long as it doesn't rely on x86 machine code to do the job (which I doubt).
idky google locked down the architecture in the builds and didn't just leae it as any old gnu/linux or whatever and let the person making the build tweek any bugs, instead of having to hack googles custom build system for building the toold chain to for a specific architecture.
floowing some rough profiling
jthree2001 said:
I really like this idea and I've been looking for something like this. You said you used the "X server" android app? I'm kind of curious on the performance. Was it laggy or just that it wasn't fully what you expected?
Click to expand...
Click to collapse
Ok, I did some crude profiling using the setup
tightvncserver
xrdp
and xrdp client on android.
the major bottle neck was the rdp client on android which made my testing cpu limited since it was maxing out cpu usage. I beleive this may be due to a bug in Android on my tablet relating to non opengl es graphics..
anyhow I got some more usefull data
xrdp was typically sitting at around 40% cpu and all it's doing is taking data from tightvnc and shunting it over rdp to the client.
next on the list was the vncserver using typically less than 30% cpu.
I think this shows there is clearly a lot of overhead (based on the 40% cpu xrdp was using) of using a remote desktop protocol over sockets that should be easy to mitigate by using shared memory.
I also tried a different setup
tightvncserver
and a vnc client on android
taking rdp out of the loop
again the android client made the tests cpu limited but perforance was much better.
This VNC client is open source, so my next step is to create an opensource project and modify the VNC client so that the user input is up to scratch and look at using opengl for graphics (assuming that's where the bottle neck is) so that it's not longer cpu limited.
Once that is done (which should also failarize me with the VNC protocol and the client code).. I can look at replacing the graphics part of VNC with a shared memory buffer, but keeping the user IO over the existing VNC protocol as that makes sense...unless that also becomes a major issue.
That also leaves me some way of sending additional data back and forth without having to do it 'all' via shared memory which would be much more of a mission
in theory there shouldn't be any need for any kind of complicated mutexing between the android client and the x server sine the x server will be all but write only and the android client always read only.
on a side note,
running java linpack on android I get about 50mflops per cpu
with disk io I get about 1gig per second cached reads.
so some crude math would give me 250mega words
my screen is 1920 by 1080 (well actually 1200), but we'll call that 2k by 1k, or 2 mega words.
so a theoretical performance into the high tens of fps seems quite achievable, which is much bettern that the 5 or so tops that I'm getting atm by an order of magnitute.
having a quick poke around, mostly related to my xorg wows (that is it complaints about no tty device when starting up. it seems that it's not too difficult to get xorg running using a frame buffer driver after a few android services have been stopped. So i'm not sure if this is still needed or not.. IPC betwen gnu and android is still an interesting project.
So anyhow, I'm going to try and get xorg running properly, there are even tegra 3 drivers for xorg too, so in theory the performance should be substantially better than anything an ipc hack would be able to achieve.
Hi everyone
I've been coding games in OpenGL ES 2, 100% in JAVA. My question : Will I have a performance boost (in FPS) if I coded some parts of my games in C++ ? Like the rendering part ect. Can I have an estimation ? (2x, ect.)
Also, C++ is compiled, so I suppose I will need to make 2 APKs, one for ARM and an other for x86 ?
kamuikun said:
Hi everyone
I've been coding games in OpenGL ES 2, 100% in JAVA. My question : Will I have a performance boost (in FPS) if I coded some parts of my games in C++ ? Like the rendering part ect. Can I have an estimation ? (2x, ect.)
Also, C++ is compiled, so I suppose I will need to make 2 APKs, one for ARM and an other for x86 ?
Click to expand...
Click to collapse
You will have performance boost, c++ runs natively while java runs on vm
How much boost i don't know, i have never used c/c++. On today's modern hardware i presume not too much
You can make 2 apks, google play store allows adding separate apks for each supported architecture (mips, arm, x86)
But you dont have to if you dont want.
You can compile native libraries for both arm and x86. Then in java you determine which one to use
Thanks for your answer
Can someone that actually did the jump (from JAVA to C++) share about his experience ? Hom much FPS boost should I expect ?
I have a simple scene right now in 100% JAVA that is rendered at 17 FPS on an old mono 1 GHZ device, which is quite low. I was wondering if I optimized the rendering in C++ I would have 60 FPS on that device...
I can't talk from an OpenGL point of view but I made an Equation Solver a while back using the NDK and C++ as the engine for it. I can say the performance increase is quite dramatic.
http://www.youtube.com/watch?v=pHS4aXqPo-A
Go to 7:30, it shows an application that executes the same algorithm via Java and Native. You can see a large difference in performance.
It depends on what you're doing. If you have some heavy physics engine or massive calculation of whatever else you gain a lot by using the NDK in addition to the SDK. Small calculations and simple games aren't worth the overhead because each call to native code via JNI has a huge impact.
C++ performance gain
Hi,
Indeed you should expect performance gain, as a rule of thumb, C si between 3x and 50x faster than Java and C++ is roughly 3% slower than C. These were the figures of 2000, Java might have been improving since. Definetly, you will have a performance boost. For all serious animated games, it should be C++, no doubt.
There might be a trick to compile C++ code at runtime saving you the burden to compile for all platforms. For instance, for RenderScript, which allows computation on GPU, the C code (C99) is compiled at runtime.
Hope this will help.
DP
It could be faster. Remember Java & C++ have quite a few differences: no garbage collection in C++, pointers, no reflection for example. Not trying to put you off but it could mean altering your design to compensate. Having said that I have used JNI in a project years ago to talk to some hardware (not for performance) & that was no problem.
it is not easy from java to c++. c++ has some concept very different with java. for example pointer, free, delete memory. i think how to manage the memory space is very hard to java engineer.
kamuikun said:
I've been coding games in OpenGL ES 2, 100% in JAVA. My question : Will I have a performance boost (in FPS) if I coded some parts of my games in C++ ? Like the rendering part ect. Can I have an estimation ? (2x, ect.)
Click to expand...
Click to collapse
Nice stone age writing (for/about loopers) with some metrics
The first think I recommend you is to profile your code and get a clear idea of where is most of the time spent, if your time is mostly spent on gpu / draw calls then I don't think language is your problem.
my experience
I initially implemented my PlotimFree plotting app with Java and was not satisfied with the results. For the move to C++ I gave the Marmalade sdk a shot, and while I;m not sure I'd use it again if I started from scratch (due to pretty awful support), the performance boost was amazing. I expect pure NDK to be at least as good.
About two versions: Indeed, you need to compile for each target separately, which Marmalade limits, depending on the license you acquire. And there are a few more targets besides Arm and x86. I can testify, though, that converting my Android app to BB10 (which is also Arm based but still a different target) was no more than a two hour process.
Lyonsbane said:
The first think I recommend you is to profile your code and get a clear idea of where is most of the time spent, if your time is mostly spent on gpu / draw calls then I don't think language is your problem.
Click to expand...
Click to collapse
This is exactly right, profile first and find out what is consuming the most processing time. Then from there you can determine if that component is something you can write natively in C and invoke from your Java code.
kamuikun said:
Hi everyone
I've been coding games in OpenGL ES 2, 100% in JAVA. My question : Will I have a performance boost (in FPS) if I coded some parts of my games in C++ ? Like the rendering part ect. Can I have an estimation ? (2x, ect.)
Also, C++ is compiled, so I suppose I will need to make 2 APKs, one for ARM and an other for x86 ?
Click to expand...
Click to collapse
It depends on your skills, I would consider to include shades rather than migrating to different language.
As others have mentioned.. maybe look at the way you are rendering or the shaders. On most Android devices now we have a JIT, this basically compiles sections of the Java code at runtime to the platforms native format.
Many times I consider switching to C++ but really cannot convince myself yet! The main benefits I see to it are:
- No garbage collector, so hopefully you can control your allocations more easily
- Platform independence, you can write most of your code in modules and keep non-platform specific parts away to make it easier to port later.
A lot depends on the quality of your Java code as well.
A big problem with doing graphics in Java is getting things smooth. If you create a lot of objects each frame, you will overload the garbage collector, and every few seconds, you will see a slowdown.
C++ won't suffer from this issue.
I have done a Java software rendering demo years ago (search for 'Croissant 9' on pouet.net), and spent a lot of time on minimizing the load on the garbage collector by re-using objects with a simple pool system, so that the demo ran smoothly throughout.
I recently tried to port it to Android, and found that Dalvik is worse at memory management than the JVMs I used 10 years ago when developing the original demo. Dalvik is also a lot slower. The original ran fine even on simple 1.6 GHz Northwood Celeron, easily 30-50 fps... A modern high-end Android phone should be faster, but the code runs with single-digit framerates.
So there's a lot to gain with C++ there.
But with hardware rendering, the bottleneck is not so much on the CPU, but on the GPU, if your code is designed properly.
As for APKs, I believe if you just add multiple platforms to your makefile, it will pack the multiple platforms into a single APK, and the proper code will get deployed on the device automatically.
I can confirm what many of the pro-C++ posts are saying, but I can also correct a few assumptions about Java development for OpenGL ES 2 targets.
I have decades of experience in C/C++, with targets ranging from 3D engines to robotics control systems.
Most of the high performance work you see on Android devices was written in C++, not Java.
There is very little if any benefit, contrary to the Android documentation, in mixing Java and C++ together. The JNI interface is a considerble bottleneck. If you're going to work in C++ for OpenGL ES 2 targets, you should work entirely in C++ - viewing the Java nature of Android applications as a necessary evil for getting I/O from touch.
There are a number of free C++ engines targeting Android. I can't heartily recommend them for you, but they exist as examples from which to base judgement. One that you can EASILY unpack and compare right now is GamePlay3D - from Blackberry (I know, it's a surprise source). With that, and the NDK, you can build 3D example games from the package and see for yourself what an all C++ development target does on your device.
Contrary to Google's claims, Java is slow by the standards expected from engineers familiary with C++ development. Little to zero can be done to change that. However, C++ is a complicated language to use effectively. The learning curve is steep, the potential perils are high and for Android it was an unwelcome, highly resisted addition to the platform (when the NDK was introduced). Since NDK 7 C++ has become a relatively first class member of Android development work, and virtually all high performance games use it for both portability and performance.
A lot of people seem to expect all kinds of magic performance improvements from going to C++, without realizing that their graphics coding might be sub-optimal. Too many state changes, too many draw calls, textures that are too big or shaders that are too complex, those are all quite common causes of slow graphics that are not going to be fixed by moving to C++.
Sure, if you really need every last bit of performance (and you know how to get it), go with C++. But given the power of todays hardware, most people should be able to get by just fine with Java.
It would be a different story if you're planning to port your stuff to IOS: then coding in C++ actually makes sense. I also do a lot of OpenGL stuff in C++; simply because it allows me to plug the renderer into a Qt application on the desktop, avoiding the upload to the device, and making debugging a lot easier.
BTW: the pain of writing JNI code can be eased a lot by using SWIG, which generates all the required wrapper code based on interface definitions.
Crossbreeder is an 5in1 package created to make Android devices run faster with less lag and to give a significant performance boost.
Tested and confirmed to give our wildfires a considerable boost. Tested on CM6, CM7, CM9.
head to the original thread to get the flashable ZIP. and please remember to read the OP carefully before using this.
Zip files are also attached to this post.
Original Thread -
forum.xda-developers.com/showthread.php?t=2113150
all credit goes to idcrisis for creating this package. I'm just sharing this with my fellow buzzers.
what Crossbreeder actually do, QUOTED FROM ORIGINAL POST,
This is a combination of 5 different
key methodologies to improve the
Android experience:
1. It's a big new feature, DNS
caching, parallelising and tether
boost . A lot of the lag in a lot of
apps, apart from the GUI lag, is due
to slow DNS querying, specially on
the mobile network.
CrossBreeder now runs a caching,
parallelising DNS client on the
device. So now most of your DNS
queries will be served from the
cache and if not found, the query
will be sent in in parallel to
multiple DNS servers including the
two Google DNS servers and your
two ISP servers and the quickest
reply will be served to you, hot and
transparent. You can read this
rationale for this approach - http://
ma.ttwagner.com/make-dns-fly-...q-
all-servers/
This speeds up network access and
networked apps, like Browsers of
course, and Tapatalk, Gmail and
thousands of others drastically. And
removes a lot of the lag where it was
due to DNS querying. This will not
increase your network or download
speed but pages will load much
faster.
This will future proof your devices as
more and more apps start using
HTML5 and/or reside completely as
web pages or the like.
CrossBreeder boosts your tethering
connection. Client devices to your
device will take advantage of the
new DNS. Hence their usage is also
improved! In many cases this update
might even fix a broken tethering
feature on your phone. So if your
ROM doesn't have a working
tethering support, you an try and
install this update. It might
magically start working!
CrossBreeder blocks ads and
spyware in an efficient manner by
blocking access to the host. It does
this using a static block list of known
ad sites and behaving as an
authoritative DNS server for these
sites and redirecting them to a
dummy address. CrossBreeder runs a
simple web server serving empty
images and pages, so ads completely
disappear instead of showing an ugly
Page/Image Not found error.
You can update this block list from
an external specialised tool like
Adaway if you need
It also renames any existing /etc/
hosts file on your device. Testing
has proven that keeping a system
wide /etc/hosts file as is used by
most other Ad blocking software
actually slows down your system. So
it is recommended to use this
method instead. Check this out for
the demonstration of the slowdown
and how to test it yourself - http://
forum.xda-developers.com/
show...php?p=41877518
In order to achieve all this DNS
related functionality, CrossBreeder
relies on the excellent open source
utilities - DNRD and Dnsmasq
2. Modulate OS entropy levels for
lag reduction ala Seeder. The whole
OS reads either /dev/random or /
dev/urandom and both need
entropy. However this mod uses a
completely different, lightweight and
efficient random number generator
called Havege . This sharply reduces
cpu consumption and corresponding
battery life loss compared to Seeder.
It also does a better job at keeping
entropy levels high hence your
device is more responsive. It doesn't
run in a CPU intensive loop either.
The extend queue functionality has
also been added to CrossBreeder.
See here for another rationale
favouring Havege compared to Rngd
- ( http://code.google.com/p/csrng/ -
Look for the limitations.)
3. Change kernel parameters
specially the wakeup threshold ones
so read blocks are released instantly
and writes never wake up as we have
an external entropy generator. And a
host of other fail safe and working
tweaks from the community for each
key subsystem. ( one can look
inside /etc/CrossBreeder/
zzCrossBreeder ).
4. Remove /dev/random as it's
blocking . Link it to non-blocking /
dev/urandom. Since /dev/random is
blocking and designed to protect us
from Quantum alien cryptographers
with mathematical certainty and
urandom is non blocking pseudo-
random device that most apps and
OSs are using anyway and with
Haveged running, is as secure
anyway as it's very difficult to empty
the entropy pool faster than Havege
can replenish it. Pre ICS devices
have a lot to gain with this but ICS+
devices show visible gains too.
5. Frandom support (Optional) -
CrossBreeder now supports linking
both your random devices to the
extremely fast alternative - Frandom
( http://billauer.co.il/
frandom.html ). This module is
orders of magnitude (10-50 times)
faster than the standard character
devices ( Check this out - http://
forum.xda-developers.com/
show...&postcount=134 ). The
erandom character device also
installed by Frandom doesn't use up
system entropy at all on top of being
fast. You will need to ask your ROM
developer to develop the kernel
module for you and then place it
in /system/lib/modules.
CrossBreeder will then try and load
it and if successful, make all the
necessary adjustments so that both /
dev/random and /dev/urandom are
pointing to /dev/frandom and /dev/
erandom respectively. The speed
benefits are to be seen to be
believed. But since each ROM
requires a unique kernel module,
this option is left optional ( but
auto detect ). Advanced users can
even try and load the frandom
module built for other kernels if
they don't have one readily available
for their own kernel version using
the Punchmod utility. Read this:
http://forum.xda-developers.com/
show...5#post41920265
remember to download both Crossbreeder and uninstall ZIP files. it's very unlikely that crossbreeder will cause any problems, but it's better to be prepared.
Feedbacks are welcome
Edit - Attachments will no longer be updated. Visit the original thread for latest versions.
lakshan_456 said:
Crossbreeder is an 5in1 package created to make Android devices run faster with less lag and to give a significant performance boost.
Tested and confirmed to give our wildfires a considerable boost. Tested on CM6, CM7, CM9.
head to the original thread to get the flashable ZIP. and please remember to read the OP carefully before using this.
Zip files are also attached to this post.
Original Thread -
forum.xda-developers.com/showthread.php?t=21131500
all credit goes to idcrisis for creating this package. I'm just sharing this with my fellow buzzers.
what Crossbreeder actually do, QUOTED FROM ORIGINAL POST,
This is a combination of 5 different
key methodologies to improve the
Android experience:
1. It's a big new feature, DNS
caching, parallelising and tether
boost . A lot of the lag in a lot of
apps, apart from the GUI lag, is due
to slow DNS querying, specially on
the mobile network.
CrossBreeder now runs a caching,
parallelising DNS client on the
device. So now most of your DNS
queries will be served from the
cache and if not found, the query
will be sent in in parallel to
multiple DNS servers including the
two Google DNS servers and your
two ISP servers and the quickest
reply will be served to you, hot and
transparent. You can read this
rationale for this approach - http://
ma.ttwagner.com/make-dns-fly-...q-
all-servers/
This speeds up network access and
networked apps, like Browsers of
course, and Tapatalk, Gmail and
thousands of others drastically. And
removes a lot of the lag where it was
due to DNS querying. This will not
increase your network or download
speed but pages will load much
faster.
This will future proof your devices as
more and more apps start using
HTML5 and/or reside completely as
web pages or the like.
CrossBreeder boosts your tethering
connection. Client devices to your
device will take advantage of the
new DNS. Hence their usage is also
improved! In many cases this update
might even fix a broken tethering
feature on your phone. So if your
ROM doesn't have a working
tethering support, you an try and
install this update. It might
magically start working!
CrossBreeder blocks ads and
spyware in an efficient manner by
blocking access to the host. It does
this using a static block list of known
ad sites and behaving as an
authoritative DNS server for these
sites and redirecting them to a
dummy address. CrossBreeder runs a
simple web server serving empty
images and pages, so ads completely
disappear instead of showing an ugly
Page/Image Not found error.
You can update this block list from
an external specialised tool like
Adaway if you need
It also renames any existing /etc/
hosts file on your device. Testing
has proven that keeping a system
wide /etc/hosts file as is used by
most other Ad blocking software
actually slows down your system. So
it is recommended to use this
method instead. Check this out for
the demonstration of the slowdown
and how to test it yourself - http://
forum.xda-developers.com/
show...php?p=41877518
In order to achieve all this DNS
related functionality, CrossBreeder
relies on the excellent open source
utilities - DNRD and Dnsmasq
2. Modulate OS entropy levels for
lag reduction ala Seeder. The whole
OS reads either /dev/random or /
dev/urandom and both need
entropy. However this mod uses a
completely different, lightweight and
efficient random number generator
called Havege . This sharply reduces
cpu consumption and corresponding
battery life loss compared to Seeder.
It also does a better job at keeping
entropy levels high hence your
device is more responsive. It doesn't
run in a CPU intensive loop either.
The extend queue functionality has
also been added to CrossBreeder.
See here for another rationale
favouring Havege compared to Rngd
- ( http://code.google.com/p/csrng/ -
Look for the limitations.)
3. Change kernel parameters
specially the wakeup threshold ones
so read blocks are released instantly
and writes never wake up as we have
an external entropy generator. And a
host of other fail safe and working
tweaks from the community for each
key subsystem. ( one can look
inside /etc/CrossBreeder/
zzCrossBreeder ).
4. Remove /dev/random as it's
blocking . Link it to non-blocking /
dev/urandom. Since /dev/random is
blocking and designed to protect us
from Quantum alien cryptographers
with mathematical certainty and
urandom is non blocking pseudo-
random device that most apps and
OSs are using anyway and with
Haveged running, is as secure
anyway as it's very difficult to empty
the entropy pool faster than Havege
can replenish it. Pre ICS devices
have a lot to gain with this but ICS+
devices show visible gains too.
5. Frandom support (Optional) -
CrossBreeder now supports linking
both your random devices to the
extremely fast alternative - Frandom
( http://billauer.co.il/
frandom.html ). This module is
orders of magnitude (10-50 times)
faster than the standard character
devices ( Check this out - http://
forum.xda-developers.com/
show...&postcount=134 ). The
erandom character device also
installed by Frandom doesn't use up
system entropy at all on top of being
fast. You will need to ask your ROM
developer to develop the kernel
module for you and then place it
in /system/lib/modules.
CrossBreeder will then try and load
it and if successful, make all the
necessary adjustments so that both /
dev/random and /dev/urandom are
pointing to /dev/frandom and /dev/
erandom respectively. The speed
benefits are to be seen to be
believed. But since each ROM
requires a unique kernel module,
this option is left optional ( but
auto detect ). Advanced users can
even try and load the frandom
module built for other kernels if
they don't have one readily available
for their own kernel version using
the Punchmod utility. Read this:
http://forum.xda-developers.com/
show...5#post41920265
remember to download both Crossbreeder and uninstall ZIP files. it's very unlikely that crossbreeder will cause any problems, but it's better to be prepared.
Feedbacks are welcomed
Click to expand...
Click to collapse
Tested on rempuzzle, change nothing , will test other thing.
And Tested on miui v2.3,it improve the performances.
On aokp v5, it make bootloop when We usés the ROM too long ( without oc ).
On miui v4, improve stability.
Sent from my HTC Wildfire using xda app-developers app
Pator57 said:
Tested on rempuzzle, change nothing , will test other thing.
And Tested on miui v2.3,it improve the performances.
On aokp v5, it make bootloop when We usés the ROM too long ( without oc ).
On miui v4, improve stability.
Sent from my HTC Wildfire using xda app-developers app
Click to expand...
Click to collapse
well,rempuzzle probably don't need this, since its fast enough as it is now. but it would have been great if this worked.
I think aokp v5 has seeder intergrated, maybe they are conflicting with each other. but crossbreeder says it prevents seeder from executing, so I'm not sure.
anyway thanks for the info
but crossbreeder says it prevents seeder from executing, so I'm not sure.
Click to expand...
Click to collapse
It does. I had that myself when crossbreeder stopped seeder app automatically after having flashed it.
gerope said:
It does. I had that myself when crossbreeder stopped seeder app automatically after having flashed it.
Click to expand...
Click to collapse
yes, I know it does, I was just guessing a probable cause for the bootloop.
Maybe it's something else, better leave that to devs to look into.
Tested this on DK froyo ROM. It does make a difference.
Sent from my HTC Wildfire using Tapatalk 2
Updated Attached files to latest version (6.23.13_v2)
If your current Kernel doesn't support Init.d executions, try an app like Universel Init.d
https://play.google.com/store/apps/...&utm_medium=organic&utm_term=universal+init.d
Pator57 said:
Tested on rempuzzle, change nothing , will test other thing.
And Tested on miui v2.3,it improve the performances.
On aokp v5, it make bootloop when We usés the ROM too long ( without oc ).
On miui v4, improve stability.
Sent from my HTC Wildfire using xda app-developers app
Click to expand...
Click to collapse
I flashed AOKP v5 and deleted the seeder script from Init.d folder after flashing Crossbreeder, and I did not experience any bootoops while I was using that ROM ( I used it for about 2 weeks)
Does Rempuzzle support Init.d scripts?
lakshan_456 said:
I flashed AOKP v5 and deleted the seeder script from Init.d folder after flashing Crossbreeder, and I did not experience any bootoops while I was using that ROM ( I used it for about 2 weeks)
Does Rempuzzle support Init.d scripts?
Click to expand...
Click to collapse
Yea, im sure.
Sent from my HTC Wildfire using xda app-developers app
Definitely, this mod effects, cm7 becomes smoother.
while coming out of app drawer back to main screen, scrolling has also improved.
Thanks
Sent from my HTC Wildfire using Tapatalk 2
Intresting..
Thnx for this m8 Going to try hopefully it will reduce many lags :]
-------------------------------
Btw i'm new to this all :] :good:
New update available.
Visit the Original thread for more info and downloads.
http://forum.xda-developers.com/showthread.php?t=2113150
I've noticed two ways to speed up ChromeOS (and forks) that I *think* (let me know if I'm wrong) would be pretty easy to implement.
First, the filesystem. I noticed chromeos-install seems to use ext4 by default, with just a bunch of "mkfs.ext4" commands...
Could we just swap out all the mkfs.ext4's with mkfs.f2fs, and enjoy a free speedup on SSDs (which most chromebooks have)?
Second, and I'm less sure of how to do this, but using more compile-time optimization (like -O3 instead of -O2). Since ChromeOS is based on Gentoo it should be at least possible. Here's an example of a Gentoo overlay with the sort of optimizations I'm talking about. IDK if this would be plug-and-play or not though with ChromeOS.
Also, let me know if you've gotten any other interesting speedups working
well some expert should check this please....