Related
Until Vilord get's back and can post it in his other thread. Here is a kernel for ECLAIR ONLY that will help with open gl performance it's not setting permission properly on boot yet, but when the system's booted chmod a+rw /dev/msm_hw3d* than stop/start. Again I'm sure if I don't Vilord will get the permissions fixed up when he's back.
Big thanks to DZO again for applying all of the needed changes
The google live wallpapers do not work properly, however the visualization papers do, as well as the wallpapers from the market because they are written in just open gl, not lite.
This brings neocore results from 01.6 to 15.6 fps!
Results may vary.. (I like that phraze )
Download
http://www.mediafire.com/?sharekey=f6ec00ed7ed721a8d0d290dca69ceb5cf8913d4b9300395c16f8cf40558950b4
If you like my work and would like to donate me a beer you can by clicking here Beer Me
where's it located?
posted them to media fire. When Vilords back we'll put them on sourceforge.
FREAKING SWEET!!!!
You Da Man!!!
Is there a zImage version available for haret? thanks.
If you had to remove libGLES_qcom.so I'm not quite sure how you're actually getting hardware graphics, since it's the driver...
Is this only for 3D animation on home screen or are we likely to see any performance upgrades during day-to-day use of Eclair (as in screen scrolling or switching between apps).
Pl clarify.
bri3d said:
If you had to remove libGLES_qcom.so I'm not quite sure how you're actually getting hardware graphics, since it's the driver...
Click to expand...
Click to collapse
bri3d. hit me up on gtalk.
After realizing the permissions weren't being set properly still I set them with the commands in the first post.
There is a definite increase in some of the live wallpapers however some do not work properly at all now. I believe it is because of opengl es lite not being supported. As example the grass wallpaper now only has a white background, although the grass looks alot better. lol. Wallpapers off the market are much smoother now.
however this is a huge step in the right direction
Seeing the same issues - it's a shame the current Q3Dimension driver for this chipset doesn't support everything Live Wallpapers want. On the other hand, the couple games I've tested thus far work, along with Street View.
"Grass," "Spectrum," and "Polar Clock" (after changing the colors in the options, thanks mssmison!) seem to be the only live wallpapers that work for me (Cube does too, but it's not GL) - Magic Smoke crashes on 320x240 due to a bug in the wallpaper itself (mssmison confirms it works fine on bigger resolutions), Galaxy uses an unimplemented GLES call, Nexus just doesn't work (this is the one that confuses me most - no unimplemented call errors and the GPU allocates just fine, just doesn't display anything), Water's got some unimplemented calls too.
We'll see if a newer Q3Dimension version ever surfaces or downport wallpapers - until then, I think this is parity with official MSM7500 devices so it's about the best we can do.
bri3d said:
"Grass," "Spectrum," and "Polar Clock" (after changing the colors in the options, thanks mssmison!) seem to be the only live wallpapers that work for me (Cube does too, but it's not GL)
Click to expand...
Click to collapse
Interesting about changing colours - I'm running into an issue where the bootanimation on heroblend on the nomorootfs nand (or nand 2.0) completely whites out - I've replaced with a different bootanimation and it works fine.
Are there some colours out of limits?
When I ran this on my Vogue it made everything super huge...what did I do wrong?
plemen said:
Interesting about changing colours - I'm running into an issue where the bootanimation on heroblend on the nomorootfs nand (or nand 2.0) completely whites out - I've replaced with a different bootanimation and it works fine.
Are there some colours out of limits?
Click to expand...
Click to collapse
yes there are, I havent had time to go through and define them as of yet.
mssmison said:
Until Vilord get's back and can post it in his other thread. Here is a kernel for ECLAIR ONLY that will help with open gl performance it's not setting permission properly on boot yet, but when the system's booted chmod a+rw /dev/msm_hw3d* than stop/start.
If you like my work and would like to donate me a beer you can by clicking here Beer Me
Click to expand...
Click to collapse
A little help please- is it one line in terminal:
chmod a+rw /dev/msm_hw3d*
or is there another line? What do you mean by "than stop/start"?
So if I already flashed to mssmison's 2.1 build using the 480 nbh then changed the density to 120 and flashed to 320 nbh, what exactly do I do with this .nbh? Do I have to start from scratch or can I use the volume up menu to update?
hexto said:
So if I already flashed to mssmison's 2.1 build using the 480 nbh then changed the density to 120 and flashed to 320 nbh, what exactly do I do with this .nbh? Do I have to start from scratch or can I use the volume up menu to update?
Click to expand...
Click to collapse
What are you trying to do? If you are trying to get the dialer to fit correctly download the qgva update tar file. Open it using 7 zip after download and open the build.prop file change the density to 110 save it and run the update tar file via the new installer.
Reddog80p said:
What are you trying to do? If you are trying to get the dialer to fit correctly download the qgva update tar file. Open it using 7 zip after download and open the build.prop file change the density to 110 save it and run the update tar file via the new installer.
Click to expand...
Click to collapse
Trying to get HW3D working
hexto said:
Trying to get HW3D working
Click to expand...
Click to collapse
Flash the nbh from the first post in this thread then run the app from this post under opengl support..
http://forum.xda-developers.com/showpost.php?p=5486428&postcount=1
Has anyone ran into problems with Opengl textures on Froyo 2.2, cant seem to get the textured triangle sample to display a texture on my 2.2 nexus one, works fine on the 2.1 emulator. But when I build and run the API demos from the SDK and select the texture triangle it works fine, this is driving me crazy why the same code doesnt display any textures if it’s built as a standalown app. I have tried adding ‘nodpi’ and ‘drawable’ dir’s with the texture images too.
Oh I'm pretty sure it worked fine when my nexus one was running 2.1.
Thanks
Think I solved it, i will post the fix later.
So what was the problem? I'm experiencing this to. I noticed the issue happens if I have ndroid:anyDensity="true" in my app manifest, but if I use anything else, I don't get the full 800x480 screen resolution available to me.
Same issue is happening to me as well. My little opengl 2D test app ran fine in my Nexus 2.1 and after upgrading to 2.2 textures are completely white. Would you please tell us what was your problem?
Thanks!
I think I have your solution.
First, as people may already know, to get the full resolution you want <supports-screens android:anyDensity="true" /> in your application manifest.
The textures are white because when you load them from a Bitmap, android has resized them and the resizing has made them a size that is not a power of 2, so it borks when you load the texture into opengl.
So how to you stop Bitmap from doing that?
create a folder in your "res" directory called "drawable-nodpi" and move your images in to that folder and the system will stop resizing them.
this is only an issue if you are using resources, if you load your images from assets or some other place, then I don't think the system resizes them.
Hope this helps, it worked for me.
-James
Hey James, thanks for your insight
However I just did as you said but I'm still getting the same result. I never used power of 2 textures and they were perfectly rendered; I'm guessing GLUtils.texImage2D already does the dirty work.
anyDensity is set to true, bitmaps are inside drawable-nodpi, all screens are set in SupportedScreens... dunno; I'll guess I'll try to load the texture from elsewhere, not the resources, and see if I can pinpoint the problem.
Hi,
I almost forgot to post here. All James said is true and doing as he said (and using power of 2 widths & height for textures) made it work, but a special circumstance was blurring my point of view here.
The circumstance is that NPOTs seem to be supported in Nexus One with Android 2.1, but not 2.2. Why this support was removed remains a mystery to me
Sorry about not posting what I found and I dont have thread update email reminders turned on. All I did was strip down the api demo (which works) to just a single project and used it as a template.
After some poking and prodding at my A7+, I was surprised by some of it's short comings. A couple in particular are easily rectified. The following changes require root access and some means of editing your /system/build.prop file (Root Explorer is real nice).
The first problem was that the screen was not as sharp and crisp as I would have expected for a 7 inch tablet running at 1024x600. As someone on these forums pointed out the LCD density is set incorrectly for the display, and that causes some problems with position/size of things in various apps. To fix this you need to change a line in /system/build.prop.
Code:
Default: ro.sf.lcd_density=200
Correct: ro.sf.lcd_density=160
The next problem is that the device reports OpenGL ES 1.1 when queried through the Android APIs, but when queried through the OpenGL APIs it reports OpenGL ES 2.0. This is a kinda big problem if you like playing indie games because few programmers will bother with low level calls when there is a decent framework to take care of that for them (let's them focus on their product instead of the boilerplate under it). To change this so that it reports correctly in the Android APIs you must add the following to the bottom of /system/build.prop.
Code:
ro.opengles.version=131072
The last problem I've not found an elegant solution for. The tablet doesn't seem to want to engage the second processing core unless a program explicitly demands it. The workaround for this is to install System Tuner, go to CPU, and slide the second CPU (left slider) all the way up, it will not keep this setting upon reset, it does keep it through sleep though. It is much more battery intensive with the CPU full engaged like that, so you'll want to kick it back down when you don't need it. One example where this made a huge difference: I was trying to watch a video encoded in x264 hi10p, without the second CPU engaged the video played slowly while the audio played full speed, with the second CPU engaged it played full speed without so much as a stutter.
I'm going to dig into the tablet a bit more now that I have a terminal emulator and ssh server set up on it. If there are power profiles like the stuff I've had to tweak on my laptop, can likely squeeze out a lot more performance with some fine tuning.
eideticex said:
After some poking and prodding at my A7+, I was surprised by some of it's short comings. A couple in particular are easily rectified. The following changes require root access and some means of editing your /system/build.prop file (Root Explorer is real nice).
The first problem was that the screen was not as sharp and crisp as I would have expected for a 7 inch tablet running at 1024x600. As someone on these forums pointed out the LCD density is set incorrectly for the display, and that causes some problems with position/size of things in various apps. To fix this you need to change a line in /system/build.prop.
Code:
Default: ro.sf.lcd_density=200
Correct: ro.sf.lcd_density=160
The next problem is that the device reports OpenGL ES 1.1 when queried through the Android APIs, but when queried through the OpenGL APIs it reports OpenGL ES 2.0. This is a kinda big problem if you like playing indie games because few programmers will bother with low level calls when there is a decent framework to take care of that for them (let's them focus on their product instead of the boilerplate under it). To change this so that it reports correctly in the Android APIs you must add the following to the bottom of /system/build.prop.
Code:
ro.opengles.version=131072
Click to expand...
Click to collapse
Wow. The lcd change is really nice- everything is much smaller but fits and looks sharper and cleaner. I saw that same post awhile ago but didn't pay much attention to it. Videos also look better.
I'm going to dig into the tablet a bit more now that I have a terminal emulator and ssh server set up on it. If there are power profiles like the stuff I've had to tweak on my laptop, can likely squeeze out a lot more performance with some fine tuning.
Click to expand...
Click to collapse
I really hope you continue to work on this tablet- it definatly needs some work. You should talk to Jam4 over at TR about this. He is making a HC ROM, and I bet he could bake the CPU changes right into the ROM.
I'm new to this stuff but where does the density come from? when I did my own math it seemed closer to 170.
Naidosh said:
I'm new to this stuff but where does the density come from? when I did my own math it seemed closer to 170.
Click to expand...
Click to collapse
Sorry been busy with my coding projects, so haven't popped into the forums in awhile. If I'm right in assuming you calculated that based on the visible screen space and resolution, you have to consider that screens have a metal trim around the edge which covers a few pixels of width and height on each border. If you dig through the source code that eLocity released, there are padding values in place to compensate for those when rendering to the screen. Almost every display out there does this, LCDs are pretty good about minimal over size, but old CRTs would have as much as 20% of the screen tucked behind the bezel for a nice border.
I am working with a partner in developing an app that would go in between the apps and basically control it in order to show a uniform control of the pixels. Basically what we are trying to do is have pixel level control of the display regardless of the content on the phone.
My Questions are:
1. Does the smartphone developer API provide access to the frame buffer of the display, which can be modified for each frame that is displayed on the screen?
2. Does the smartphone have enough time to run a 2D filter on each frame before it gets displayed? Will the phone processor be fast enough that you can filter each image and still keep up with the output frame rate (e.g. 30 frames per second). Each calculation that will need to be calculated takes time for the processor to calculate, but how much? Can the phone do all of the calculations it will need to under 1/30 seconds AND keep up with normal app processing without affecting the overall frame rate. Much of this is based on the software that is developed to solve the problem, so the real question really isn't "Does the phone have enough real time," but rather " is the phone fast enough to handle a garden variety 2D convolution on top of everything it already does".
3. Will this level of control be achievable without root to be able to reach more people with unrooted devices or is this achievable only by root level permissions.
I do hope I am in the right area to post this very important question in the the development process. We need to get this sorted out first before we can begin programming.
All the help would be very much appreciated. Thanks xda!
kennyx13 said:
I am working with a partner in developing an app that would go in between the apps and basically control it in order to show a uniform control of the pixels. Basically what we are trying to do is have pixel level control of the display regardless of the content on the phone.
My Questions are:
1. Does the smartphone developer API provide access to the frame buffer of the display, which can be modified for each frame that is displayed on the screen?
2. Does the smartphone have enough time to run a 2D filter on each frame before it gets displayed? Will the phone processor be fast enough that you can filter each image and still keep up with the output frame rate (e.g. 30 frames per second). Each calculation that will need to be calculated takes time for the processor to calculate, but how much? Can the phone do all of the calculations it will need to under 1/30 seconds AND keep up with normal app processing without affecting the overall frame rate. Much of this is based on the software that is developed to solve the problem, so the real question really isn't "Does the phone have enough real time," but rather " is the phone fast enough to handle a garden variety 2D convolution on top of everything it already does".
3. Will this level of control be achievable without root to be able to reach more people with unrooted devices or is this achievable only by root level permissions.
I do hope I am in the right area to post this very important question in the the development process. We need to get this sorted out first before we can begin programming.
All the help would be very much appreciated. Thanks xda!
Click to expand...
Click to collapse
1. I believe you're looking for "/dev/graphics/fb0" (goes up to fb3) thats the raw framebuffer.
and yes this is normally managed by the kernel (guess it's faster)
2. Simple answer is NO it does not (at least I think), I think the phone cannot manage to do such as heavy task and remain the same fps. if you build in double/tripple buffering it may differ. framebuffers is not android strongest feature xd, I think it may freeze your device, but I'm not sure. I dont have much experience in MSMFB (look it up in the kernel, how they did it)
3. not sure, but most likely root only, if you want to access it you need to chmod it to 666 atleast to access it from an app.
Code:
[email protected]:/dev/graphics # ls -la
crw-rw---- system graphics 29, 0 2014-03-21 13:06 fb0
crw-rw---- system graphics 29, 1 2014-03-21 13:06 fb1
crw-rw---- system graphics 29, 2 2014-03-21 13:06 fb2
crw-rw---- system graphics 29, 3 2014-03-21 13:06 fb3
lrwxrwxrwx root root 2014-03-21 13:06 hdmi -> /dev/graphics/fb1
links to check out that will probably help you:
https://code.google.com/p/android-fb2png/
https://code.google.com/p/fastdroid-vnc/
hope my info helps a bit
like for example there is not even a chance you can record the screen through reading framebuffers. some adb
broodplank1337 said:
1. I believe you're looking for "/dev/graphics/fb0" (goes up to fb3) thats the raw framebuffer.
and yes this is normally managed by the kernel (guess it's faster)
2. Simple answer is NO it does not (at least I think), I think the phone cannot manage to do such as heavy task and remain the same fps. if you build in double/tripple buffering it may differ. framebuffers is not android strongest feature xd, I think it may freeze your device, but I'm not sure. I dont have much experience in MSMFB (look it up in the kernel, how they did it)
3. not sure, but most likely root only, if you want to access it you need to chmod it to 666 atleast to access it from an app.
Code:
[email protected]:/dev/graphics # ls -la
crw-rw---- system graphics 29, 0 2014-03-21 13:06 fb0
crw-rw---- system graphics 29, 1 2014-03-21 13:06 fb1
crw-rw---- system graphics 29, 2 2014-03-21 13:06 fb2
crw-rw---- system graphics 29, 3 2014-03-21 13:06 fb3
lrwxrwxrwx root root 2014-03-21 13:06 hdmi -> /dev/graphics/fb1
links to check out that will probably help you:
https://code.google.com/p/android-fb2png/
https://code.google.com/p/fastdroid-vnc/
hope my info helps a bit
like for example there is not even a chance you can record the screen through reading framebuffers. some adb
Click to expand...
Click to collapse
Thank you soo much for the info. All the info will really help a lot. It is always good to hear from what more experienced devs know. Thank you thank you thank you!
kennyx13 said:
Thank you soo much for the info. All the info will really help a lot. It is always good to hear from what more experienced devs know. Thank you thank you thank you!
Click to expand...
Click to collapse
You're very welcome, even though I'm also not experienced with this subject, I always share the things I DO know (Which can help people sometimes), rather then the things I don't know (those questions go to stackexchange.com (tip). And if the info I gave you is not 100% correct, some other dev may correct it and I will learn from it as well. Sharing info is always a win-win at this forums.:good:
Good luck on your poject.
broodplank1337 said:
1. I believe you're looking for "/dev/graphics/fb0" (goes up to fb3) thats the raw framebuffer.
and yes this is normally managed by the kernel (guess it's faster)
2. Simple answer is NO it does not (at least I think), I think the phone cannot manage to do such as heavy task and remain the same fps. if you build in double/tripple buffering it may differ. framebuffers is not android strongest feature xd, I think it may freeze your device, but I'm not sure. I dont have much experience in MSMFB (look it up in the kernel, how they did it)
3. not sure, but most likely root only, if you want to access it you need to chmod it to 666 atleast to access it from an app.
Code:
[email protected]:/dev/graphics # ls -la
crw-rw---- system graphics 29, 0 2014-03-21 13:06 fb0
crw-rw---- system graphics 29, 1 2014-03-21 13:06 fb1
crw-rw---- system graphics 29, 2 2014-03-21 13:06 fb2
crw-rw---- system graphics 29, 3 2014-03-21 13:06 fb3
lrwxrwxrwx root root 2014-03-21 13:06 hdmi -> /dev/graphics/fb1
links to check out that will probably help you:
https://code.google.com/p/android-fb2png/
https://code.google.com/p/fastdroid-vnc/
hope my info helps a bit
like for example there is not even a chance you can record the screen through reading framebuffers. some adb
Click to expand...
Click to collapse
I have a follow up question, I hope you can answer them too.
Is it possible to install kernel modules on an android phone if it hasn't been rooted?
Given the Linux kernel I'm fairly certain it's not possible, but it is possible that Android has made changes that don't exactly follow the Linux convention. It may be a dumb question, but it would be good to confirm absolutely.
kennyx13 said:
I have a follow up question, I hope you can answer them too.
Is it possible to install kernel modules on an android phone if it hasn't been rooted?
Given the Linux kernel I'm fairly certain it's not possible, but it is possible that Android has made changes that don't exactly follow the Linux convention. It may be a dumb question, but it would be good to confirm absolutely.
Click to expand...
Click to collapse
There is a an option actually, but it's not the easiest one. the only way of getting the modules inside a non-rooted rom is to make a custom odin image, you need to dump the current /system folder, make the adjustments and repack it, then flash it in odin along with the boot.img and you should be fine.
There is a topic in this forum that describes how to make one
broodplank1337 said:
There is a an option actually, but it's not the easiest one. the only way of getting the modules inside a non-rooted rom is to make a custom odin image, you need to dump the current /system folder, make the adjustments and repack it, then flash it in odin along with the boot.img and you should be fine.
There is a topic in this forum that describes how to make one
Click to expand...
Click to collapse
Again brood, thanks soo much for the very very good answers. it will definitely help us out.
Hi,
1.
it is quite difficult to access directly framebuffer, the most difficult will be to have something that works with many devices.
Some devices let you have direct access to framebuffer, some do not ! Some devices like Tegra work differently for example.
All of this is to say that it will depend a lot on the devices architecture ... so it is a mistake trying to access directly framebuffer.
I think you should use Android private API to access surfaceflinger which manages display on Android, that will guaranty that it should work in theory with almost any device.
2.
The speed of the process will depend a lot on what you want to do with.
But if you do it quite well, using maybe opengl api to get faster, I think the device should be fast enough.
3.
But this will work only with rooted devices, or at least you will need to execute it in a process having enough privileges on device.
Did you already start your project ? I hope this would help.
Hi Essential Phone owners,
Can someone confirm that the Essential Phone has set dalvik.vm.heapsize to 36m instead of... 512m?
The build.prop in the vendor partition of the phone has this line:
dalvik.vm.heapsize=512m
// line 29
But the build.prop in the system partition has:
dalvik.vm.heapsize=36m
// line 68
Any devs know which one gets applied last? I think at the current state it would be heapsize=36m which is unusual.
For anyone that can edit build.prop on their own phone you can try this,
1. Remove dalvik.vm.heapsize=36m in system's build.prop
Or
2. Add dalvik.vm.heapsize=512m at the bottom of the system's build.prop
:angel:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
JBlaze05 said:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
Click to expand...
Click to collapse
Where did you find reports on reddit?
Anyways thanks for your input!
TFutoMaki said:
Where did you find reports on reddit?
Anyways thanks for your input!
Click to expand...
Click to collapse
this would be the thread
This means nothing...
su
getprop|grep heapsize
It's all placebo
Heap size and scrolling? Wtf. No, just no. I have a thread on here that actual helps with the scrolling. Add the following to your build prop in /system to improve scrolling lag and stutters.that other stuff would do nothing.
#Property to enable touch optimizations
persist.vendor.qti.inputopts.enable=true
persist.vendor.qti.inputopts.movetouchslop=0.6.
The 0.6 can be changed to your liking. 6 works well. Don't go past 8 or **** gets weird.
Thanks you all, I got with me the Essential phone now so yeah seems like it is system build.prop, and then vendor build.prop applies over it. Interesting stuff that I should remember
Dalvik heapsize
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
marvinxxx said:
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
Click to expand...
Click to collapse
You answered a 2 year old post...