I recently got an Optimus S and am disappointed that the camera has no exposure control. It's almost a deal breaker because it's such a step down from my old Samsung m510 flip phone's camera. I have posted at length about it on androidcentral, but here is the deal:
The Optimus S has no exposure control, even though the T definitly does, and by one review, the Optimus U does too. It's not a matter of the camera app; even apps that show an exposure slider have no effect on the exposure. (Scene modes also have no effect.) Because the hardware is so similar on all these phones, I can't believe it's simply a hardware limitation - the app, camera driver, or the interface between the driver and Android's java APIs, has to control exposure somehow in software, right?
I got ahold of some other roms, from the Optimus T and the V, and tried swapping all lib files with camera in the name - libcamera, libcamera_client, libcameraservice, and liboemcamera on both phones, and additionally libOlaCameraJNI, libOlaEngine, and libOlaMaskResource on the T. Rebooting with various combinations of those resulted in a hang on boot, crashing camera apps, or no effect at all. Also tried installing CameraApp.apk from the T's rom to no effect.
Downloaded the S and U's source code from LG, ran a diff, and noticed that the Optimus U's kernel/drivers/media/video/msm folder has some differences compared the Optimus S's, including at least one file that the S doesn't have at all that seems to send different hex codes for setting exposure values. I also think the T had similar differences from the S. So I copied the msm folder over from the U to the S, compiled the S kernel from scratch, flashed it, and verified it was actually running from my new kernel, but the camera apps still had no control over the exposure.
Flashing a custom rom from the V will allow the S to boot, but doesn't give camera control. Flashing a rom from the T will make it hang while booting.
Where else can I go with this? Is there some bridge between the kernel drivers and the Android camera API (look up Camera.Parameters in the android dev site), that I'm missing? What actually goes between a call to getMinExposureCompensation() and the kernel to find out what capabilities the camera has? Again, I don't see how the Optimus S hardware would simply not support exposure adjustments when other Optimus phones do.
Thanks!
Found Camera.java in frameworks/base/core/java/android/hardware from Google's source code. It says "This class is a client for the Camera service, which manages the actual camera hardware." Then I looked for the camera service, which I found at frameworks/base/services/camera/libcameraservice . But this is in Google's code, not LG's device-specific code, which leads me to believe that this stuff is the same across every phone. So I'm still trying to figure out where in the software exposure control happens.
Bump. Tried boggling around more folders and config files between various kernels from different versions of this phone. Am now thinking about using the ndk and modifying the original camera app. Will I be able to use it to access the hardware directly in native code and send exposure adjustments to the camera?
The file kernel/drivers/media/video/msm/isx005.c (for a Sony camera chip - how do I know if that's what's actually in my phone?) contains the following code:
It looks like the other files in kernel/drivers/media/video/msm allow have functions along the lines of [chipname]_write_exp_gain(uint16_t gain, uint32_t line).
Code:
static int32_t isx005_set_brightness(int8_t brightness)
{
int32_t rc = 0;
switch (brightness) {
case 0:
rc = isx005_i2c_write(isx005_client->addr,
0x0060, 0x80, BYTE_LEN);
if (rc < 0)
return rc;
rc = isx005_i2c_write(isx005_client->addr,
0x0061, 0x50, BYTE_LEN);
if (rc < 0)
return rc;
break;
case 1:
rc = isx005_i2c_write(isx005_client->addr,
0x0060, 0x80, BYTE_LEN);
if (rc < 0)
return rc;
rc = isx005_i2c_write(isx005_client->addr,
0x0061, 0x60, BYTE_LEN);
if (rc < 0)
return rc;
break;
case 2:
...etc.
It still seems that auto exposure control wouldn't happen in the camera firmware. Maybe I'm wrong?
edit: from the looks of these files, it seems like it's done in firmware. Still, would I be able to call these exposure functions from an application built using ndk?
Another edit: from kernel/arch/arm/configs/thunderc-sprint-perf_defconfig:
Code:
#
# Qualcomm MSM Camera And Video
#
CONFIG_MSM_CAMERA=y
# CONFIG_MSM_CAMERA_DEBUG is not set
#
# Camera Sensor Selection
#
# CONFIG_MT9T013 is not set
CONFIG_ISX005=y
CONFIG_ISX005_ROTATION_180=y
# CONFIG_MT9D112 is not set
# CONFIG_MT9P012 is not set
# etc, etc, etc - no other camera drivers enabled
TouchPad CM Mod 发布预告 原创 请勿转载 （转载也请注明出处 谢谢！）
由于大家的热烈要求，作者打算加快速度发布，基于cm 发布 a3 进行 改造
发布时间：2011-11-30之前发布
看到有人说只是UI,我想说UI确实是主要的一部分,但是如果说UI占了70%,那也包含了30%的性能优化,请关注性能的看看文字说明哦,还有小部分修改没上.
i can't add youtube ! sorry
youtube :
you tu.be/G4MC5_djpwk
另外,软件没有演示的那么多,我只是为了测试兼容性以及流畅程度,默认只是基于下面优化增加的程序,很干净,很简洁
更新内容预览：
1， 精简软件
a) 主屏幕提示（基本无用）
b) HTML查看（本地浏览器 ，有UC吧你）
c) OI文件查看器 替换成RE
d) 图库 替换成 流动图片 （图库老是意外退出）
e) ADW桌面
f) MagicSmokeWallpapers （一难看动态壁纸）
g) VisualizationWallpapers （还是难看动态壁纸）
h) Cyanbread （默认主题 难看）
i) QuickSearchBox （谷歌快速搜索）
j) CMWallpapers （CM自带壁纸 没一个好看的，挑战中国人民审美观？？？）
k) LatinIME （默认输入法 没中文 删除）
2， 增加软件
a) ADWEX 增强版 自定义功能多 很强大
b) 百度输入法pad版
c) 安卓4.0音乐
d) 波纹锁屏仿安卓4.0锁屏
e) RE文件管理器
f) GlasWidget桌面透明插件
g) 浮动图片比自带图库要好很多
3， 美化
a) 替换英文字体为Netura
b) 替换英文粗体为 Netura BLOD
c) 替换中文字体为苹果里黑体
d) 开机动画修改为4.0动画
e) 增加安卓4.0动态壁纸
4， 优化
a) 增加虚拟内存至48M，系统更加流畅
b) 禁止部分不用软件开机启动，开机加快
c) 默认开机为中文
d) 针对景德镇屏蔽google设置 host
e) 优化桌面流畅度
f) 取消清理内存时连桌面一起清除掉
g) 更正在某些情况下中文字体显示一半的问题（例如8*10桌面空间的小插件）
此mod 基于 cm系统。
应该不是4.0
不过 界面还有 ui 都修改的非常不错了，相比原生cm系统来说 对广大tp粉们是个非常大的惊喜
1，开机
2，锁屏
3，主界面
4，音乐
5，图片浏览（非4.0 视频里面有说明）
6，程序列表
7，视频
该贴已经同步到 丽小怡的微博
what the heck is this?
google translate
TouchPad CM Mod do not reprint the original release notice (reproduced also please indicate the source Thank you!)
Since everyone's clamoring for, the authors intend to speed up release, issued on a3 cm transformation
Posted :2011 -11-30 released before
Some people say just to see UI, I want to do is the main part of the UI, but if that accounted for 70% of the UI, it also includes a 30% performance optimization, please pay attention to the performance of text to see Oh, there are a small part of the No changes on.
In addition, the software does not show so much, I just to test the compatibility and fluency, the default optimization is based on the following additional procedures, very clean, very simple
Update the preview:
1, to streamline software
a) the main screen (basically useless)
b) HTML view (local browser, it you have UC)
c) OI File Viewer replaced RE
d) replace the current picture gallery (gallery always unexpectedly quits)
e) ADW Desktop
f) MagicSmokeWallpapers (an ugly wallpapers)
g) VisualizationWallpapers (or ugly wallpapers)
h) Cyanbread (default theme ugly)
i) QuickSearchBox (quick Google search)
j) CMWallpapers (CM comes with a nice wallpaper does not challenge the Chinese People's aesthetics???)
k) LatinIME (default Chinese input method did not remove)
2, increase software
a) ADWEX enhanced customization features and more powerful
b) input pad version of Baidu
c) Andrews Music 4.0
d) corrugated imitation Andrews 4.0 lock screen lock screen
e) RE File Manager
f) GlasWidget Desktop transparent plug-in
g) floating image gallery comes with much better than
3, landscaping
a) replace the English font Netura
b) replace the English Emphasis Netura BLOD
c) replace the Chinese in bold font for Apple
d) was revised to 4.0 startup animation animation
e) Increase Andrews 4.0 wallpapers
4, optimization
a) increasing the virtual memory to 48M, more streamlined system
b) do not prohibit some of the software boot, boot speed
c) the default boot into Chinese
d) set the host for the Jingdezhen shield google
e) Optimized Desktop fluency
f) To remove the desktop with the clean-up memory even when removed
g) in some cases more is half Chinese font display problem (for example, 8 * 10 small plug-in desk space)
This mod is based cm system.
4.0 should not be
However, there are ui have to modify the interface is very good, compared to the native cm system for the majority of their tp powder is a very big surprise
1, the boot
2, lock screen
3, the main interface
4, Music
5, the picture here (there are non-4.0 video description)
6, the program list
7, video
The paste has been synchronized to the micro-Bo Li Xiaoyi
Video looks like a custom/ics style theme, launcher, lockscreen, and gallery app. Can't notice anything more than that. Nice looking anyway
Hello, I come to ask only for a few tips or merely a bit of guidance on my development for Android.
I'm pretty skilled in ActionScript and new to Java. In this thread I ask how would I do some things in Java, providing the equivalent in AS.
I intend to draw shapes on screen and use them as UI - as a deeper layer within the Android XML UI.
In ActionScript, I can create Sprites or DisplayObjects, edit their "graphics" property like
// create a DisplayObject instance
_someDisplayObject = new DisplayObject();
// create a white square inside it
_someDisplayObject.graphics.beginFill(0xFFFFFF);
_someDisplayObject.graphics.drawRect(0,0,100,100);
_someDisplayObject.graphics.endFill();
// place it dinamically in a position relative to the Stage (canvas)
_someDisplayObject.x. = Stage.stageWidth / 2;
------------------
Also, are there Tweening libraries like TweenLite or Tweener ? Those which allows to create animation with one like of code like:
// move display object to position X = 300 with half transparency, in half second
Tweener.addTween(_someDisplayObject, { x:300, alpha:0.5, time:0.5, transition"EaseOutSine" } );
------------------
Can anyone give a clue, on what am I looking at, to try the same in Java for Android ?
Just an advice letting me know where to start would be greatly appreciated. :fingers-crossed:
Thank you !
You can create shapes in Android using XML or in your Java code or with both. You can also create Animations including Tween animations. (I haven't used animations before though so I can't help any further).
The first place to go is the Android Developers website (d.android.com/develop) and then in the API Guides section under User Interface option and App Resources option in the left hand menu. There are samples included in the Android SDK under API Demos which you can use to get your started.
I can't post links because I haven't made 10 posts yet, sorry.
As you already know, the Android display model is more complex than the one used in ActionScript.
There is no direct equivalent for the graphics property from AS3 in Android.
To draw low-level graphics you can use the canvas parameter provided in the onDraw method (you override it in your own class inherited from android.view.View).
As for the Tweening, like Kavrocks said, try to learn how to use the Animation class and it's extensions, because they are built inside the android framework, therefore optimized (that's just my opinion). All the tweening engines in AS3 are based on dynamic calling of properties (by name). Java uses the reflection api for calling dynamic properties, but it is much slower than a direct call (from a specialized Animation class, in this case).
I am also trying to figure out different modes of applying animations and effects in actionscript. There's a tutorial on Lynda where you can see som tips from migrating from AS to Java, and HTML5, both of this can help you understand better how to apply them in your application.
I would like to develop and app, which has the main functionality to show a 2D chart. There are others and settings, but this is the main.
Existing similar applications aren't using technologies as how it should and they are releasing apps with to few features or they are draining battery like crazy. This I would like to improve it.
This is for web / desktop
View attachment 2397770
Here are a few sentences from my experience, please correct me if I am wrong!
Many-many of implementations are using SDK and 2D graphics. They draw the whole screen every time. Just sere how your battery drained in 1-2 hours! - some really bad implementation they can drain in 3 minutes, I will show later. One exception is: Metatrader 4: it use NDK and OpenGL, Hey pay me, because I am advertising you!
I think the SDK code (.class files) it need to e compiled at runtime execution by virtual machine, which takes CPU usage.
NDK is compiled only one => will use less CPU => will drain less batter as the SDK version.
If this is correct, than it should move more code to NDK if is possible. Not sure about JNI calls overhead!
NDK huuuuge advantage: it will allow to use the phone max available memory ( 1.5GB was last time) instead of SDK max allowed value: 256MB ( in my case, but some devices allow only 24Mb for SDK apps)
If you don't touch this chart than nothing changes, if you set the "Live" option, than the last "candle" will change. The candles are those Red & Green rectangles with the line in upper side and down side with meaning of the open, high, low, close prices. - it is related to business logic, but this special bars can have those 2 lines, which are important. The border of the 1pixel black around the red-green rectangles are for visual effects only. To save battery can be omitted.
(The background text and logos are just for advertisements, nobody cares, not really needed for the user for his actions)
As you can see there is a toolbar, and there are maybe other components too, but when the user want to see highest amount of data than will rotate to landscape and there should be given a Full Screen (in portrait not by default)
I have started the development with a component for rendering with OpenGL ES 2.0.
The UI is in SDK , the renderer there is called, but the method implementation calls the native methods via JNI. The business logic, rendering implementation are all in NDK, which is a native shared library.
Not sure why I started with OpenGL, to have some cool effects, who want to drain his battery faster? or I tough if is faster than will consume less battery? - maybe faster drains, but more: 100 mA from GPU for 0.01 seconds rendering is the same as 10 mA for 0.1 rendering at CPU.
Here I am not sure if I am saving energy. Tell me your opinion!
So I have started learning OpenGL ES 2.0 and all what I saw in tutorials it was triangle triangle triangle, but in this chart there is no triangle, but rectangle, or rectangle+lines or just lines with set width or many triangles?
Here is a cool candle, I would like to see this, but I know the gradients will burn battery.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Here is a bit magnified and you can see how I am thinking:
but can't decide. Because I haven't enough experience, don't know the benchmark results. I would like to see a tear down and expected results:
GL_Lines + glLineWidth
GL_triangles
GL_triangle_strip
As the first option with GL_lines:
A candle would be 1x small line from the Low and High price drawn first. Lets say with 5 pixel width to have room for gradient too, if needed. In worse case only 1 pixel, as how they are using others now.
The candle body: the red/green rectangle with has the info of Open/Close price can be another GL_Lines with 50 pixel width - for example.
Will be gradient or not that would depends on user settings. Not sure how is possible to draw black 1-2 pixel of border for candle body in this case - if the user has that settings.
Seconds option with triangles:
2x triangle can make a square.
There is a square as the small line and there is another one the larger square : the candle body.
The triangle strip case:
if only one GL_triangle_strip:
bottomline: 4 vertices
body other 4
upper line 4 vertices
or small line 4x vertices
+
other 4x vertices , so 2x GL_triangle_strip
I made this:
The first thing it was:
Code:
setRenderMode(GLSurfaceView.RENDERMODE_WHEN_DIRTY)
It is a rectangle with 2x triangle and a line with width.
The line has less vertices of course, but in this chart is expected to have 50- 200 bars maximum. Minimum 10-20.
What is needed is that cross at mouse location: that dashed line and the numbers ( price ) on the right and some other texts in bottom. X, Y coordinates in text.
Please post your experience, benchmarks, opinion.
Hi matheszabi,
ok, your question was rather compheresive . So right way to find solution is rather complicated too.
I woudn't choose solution according to differences between JDK / NDK to same function calls of OpenGL ES 2.0
According to my experience, performance (and power consumption) is almost the same.
GLOBAL aproach: I suggest
1) you create your application in Java - use JDK versions - creating native function for just few draw calls is, imho, hard compared what you get
2) if your application is NativeActivity
- use direct calls - be prepared for differences between devices, proper creation of surface, .... but it's faster
- subclass Native Activity and use JAVA as well
3) not using OpenGL ES directly at all - i suggest trying layout and buttons / images inside of it, i saw 200 control buttons on 1 screen and it ran perfectly. And layout is movable by 1 command - offset. I suppose, this is completely written in native code anyway. You just get drawing interface in JAVA.
Now, to OPENGL ES itself (JAVA or NDK)
cons:
- OPENGL is 3D interface so pixel perfect drawing is something which is not supported by itself. (note: opengl has pixel / texel center at 0.5 not at 0.0/1.0)
- you need pixel perfect draw - boxes you draw must be perfectly aligned to screen pixels - othewise you get blurry results
- you might not need texturing - thats PLUS, otherwise drawing pixel perfect opengl suraces is "pain in the ..." - viz. texel interpolation and drawing a pixel checker aligned with screen pixels is real nightmare and it differs on each device (I tried )
- pixel perfect with mipmaps - awful again
- alpha blending (when you have something which is transparent) - you will need sorting to draw it properly
- will you need font ? oh my ...
- NO EMULATOR - will need to test each device if it's working properly (not every, at least each vendor)
to consider:
writing vertex/fragment shader in a world with 3500 (number of opengles 2.0 devices according google) suitable devices/compilers/android versions ... ehm
pluses:
- you draw exactly what you want
- use of fragment shader (alhough i suggest using gradient textures instead)
- i suggest draw primitives in vertex buffers (indexed triangles or triangle strips). Not one box by one - compose all in one array and draw it by one draw call. Doubling points in strips can help you
- instancing is not supported) but there is way surpassing this (preparing buffers with)
- i don't recommend using lines with width definition - each implementation draws this differently - and it's equal to drawing lit cylinder
- in native activity loop - handling if you need redraw - it's difficult
I would try normal android GUI first
pluses:
- you get pixel perfect draw, with / without bitmaps, images, gradients ....
- i suppose its fast enough
- no sorting needed
- redraws will be invoked when something changes
- translation / clipping will be handled internally
- no need to care about device !!! that's big plus
cons:
- zoom will be problematic
- rotations as well (but i suppose you don't need them)
note to power consupmption - both OpenGL :
just swaping screen buffers 30 per sec will deplete most of devices within 2-3 hours. But of course, doing it so only when needed is doable
But I might be wrong so best way is to decide by yourself and, of course, try it and see.
If you have qustions about drawing through ES, i'll post some samples of pixel perfect draw (from my gui)
Good luck, post your decision, and if you have some results, post them too! will be very interesting.
PS.
Petr Sovis said:
Hi matheszabi,
ok, your question was rather compheresive . So right way to find solution is rather complicated too.
I woudn't choose solution according to differences between JDK / NDK to same function calls of OpenGL ES 2.0
According to my experience, performance (and power consumption) is almost the same.
GLOBAL aproach: I suggest
1) you create your application in Java - use JDK versions - creating native function for just few draw calls is, imho, hard compared what you get
2) if your application is NativeActivity
- use direct calls - be prepared for differences between devices, proper creation of surface, .... but it's faster
- subclass Native Activity and use JAVA as well
3) not using OpenGL ES directly at all - i suggest trying layout and buttons / images inside of it, i saw 200 control buttons on 1 screen and it ran perfectly. And layout is movable by 1 command - offset. I suppose, this is completely written in native code anyway. You just get drawing interface in JAVA.
Now, to OPENGL ES itself (JAVA or NDK)
cons:
- OPENGL is 3D interface so pixel perfect drawing is something which is not supported by itself. (note: opengl has pixel / texel center at 0.5 not at 0.0/1.0)
- you need pixel perfect draw - boxes you draw must be perfectly aligned to screen pixels - othewise you get blurry results
- you might not need texturing - thats PLUS, otherwise drawing pixel perfect opengl suraces is "pain in the ..." - viz. texel interpolation and drawing a pixel checker aligned with screen pixels is real nightmare and it differs on each device (I tried )
- pixel perfect with mipmaps - awful again
- alpha blending (when you have something which is transparent) - you will need sorting to draw it properly
- will you need font ? oh my ...
- NO EMULATOR - will need to test each device if it's working properly (not every, at least each vendor)
to consider:
writing vertex/fragment shader in a world with 3500 (number of opengles 2.0 devices according google) suitable devices/compilers/android versions ... ehm
pluses:
- you draw exactly what you want
- use of fragment shader (alhough i suggest using gradient textures instead)
- i suggest draw primitives in vertex buffers (indexed triangles or triangle strips). Not one box by one - compose all in one array and draw it by one draw call. Doubling points in strips can help you
- instancing is not supported) but there is way surpassing this (preparing buffers with)
- i don't recommend using lines with width definition - each implementation draws this differently - and it's equal to drawing lit cylinder
- in native activity loop - handling if you need redraw - it's difficult
I would try normal android GUI first
pluses:
- you get pixel perfect draw, with / without bitmaps, images, gradients ....
- i suppose its fast enough
- no sorting needed
- redraws will be invoked when something changes
- translation / clipping will be handled internally
- no need to care about device !!! that's big plus
cons:
- zoom will be problematic
- rotations as well (but i suppose you don't need them)
note to power consupmption - both OpenGL :
just swaping screen buffers 30 per sec will deplete most of devices within 2-3 hours. But of course, doing it so only when needed is doable
But I might be wrong so best way is to decide by yourself and, of course, try it and see.
If you have qustions about drawing through ES, i'll post some samples of pixel perfect draw (from my gui)
Good luck, post your decision, and if you have some results, post them too! will be very interesting.
PS.
Click to expand...
Click to collapse
Hello thanks for sharing your idea experience.
I have asked in other forum a similar question.
It was a response than the GPU has optimised methods so it will have less power consumption
Also he likes to draw the whole frame not only a part - I'm case of my optimisation
Also I have asked an opengl expert and he told me to use the ortho instead of perspective projection. He has right.
Now I don't have bliry results anymore but is pixel perfect!
For benchmark I made 100 candles : 100 line + 200 triangles.
I have calculated how much is the wigth and the height for the surface => how much space can have a candle and used the matrix transformations and render it.
A nice surprise the fist time it took 18 milliseconds but after that only took 5-6 millisec the. Sdk->ndk->opengl-> SDK steps.
That is very good result on MY trash device. But I think it has a trick: the ndk gives order to render to GPU and it will return. So in those 5-6 milliseconds will start to work the GPU for who knows how much....
Note: audio , video , sensor intensive projects should be developed on real devices not at emulators.
With my method the problem is starting with text drawing and leak of knowledge.
Vbo or texture... Not sure which one but if a native 2D can do it than I can me too.
Cairo as rendering 2d engine is a bit big to include in android.
I still think the ndk is the correct place. Also is isn't so easy to watch the engine code as a decompiled SDK code
Ok! you chose your path - good for you!
18/5-6 ms is just for draw (200 triangles+100 lines) ?, or whole frame time ? Can you tell me the the device you are testing your app on ?
Note: Ortho, i didn't mean to advice perspective transform, ortho is still 3d, and pixel perfect - wait for texturing/text drawing, but you'll manage!
Just few tips to font rendering:
bitmap fonts: I can't add links so google: angelcode bmfont
font bitmap creator: google: angelcode bmfont
+ sample: google: nehe 2d_texture_font
freetype implementation - it's possible to compile it with ndk - i use it and it's simple
google: freetype
and code for starters: google: nehe freetype_fonts_in_opengl
Cheers
P.
Petr Sovis said:
Ok! you chose your path - good for you!
18/5-6 ms is just for draw (200 triangles+100 lines) ?, or whole frame time ? Can you tell me the the device you are testing your app on ?
Note: Ortho, i didn't mean to advice perspective transform, ortho is still 3d, and pixel perfect - wait for texturing/text drawing, but you'll manage!
Just few tips to font rendering:
bitmap fonts: I can't add links so google: angelcode bmfont
font bitmap creator: google: angelcode bmfont
+ sample: google: nehe 2d_texture_font
freetype implementation - it's possible to compile it with ndk - i use it and it's simple
google: freetype
and code for starters: google: nehe freetype_fonts_in_opengl
Cheers
P.
Click to expand...
Click to collapse
My phone is a THL W8S. has FHD resolution
It had a mixed layout, but better I show you:
I have misscalculated the lines positions but for now doesn't matter.
The GLSurface takes a considerable amount of the screen space and that is counted.
On a Samsung Note 10" - at least 1 year old device, lower resolution, but better CPU + GPU it is a lot less this numbers.
My device is a trash (by far not for gamming), I told you:
Hi,
ok, as I understand, the time is just for drawing 200 tris + 100 lines - ok that seems a "little to much" for that.
Besides, your device is not trash at all
I don't know if I can share my examples - but scene from app I released week ago draws 50KTris per frame with some heavy shaders (normal mapping + specular ligting from 2 light sources) and draws text over it + particles + GUI (my ndk gles2.0 engine) and I suppose it will run over 30 FPS on your device (its PoverVR 540 or something) (google play: "Asteroid Hunters" by me)
So, can you post fragment of your drawing code ? maybe there something not really right ?
P
Petr Sovis said:
So, can you post fragment of your drawing code ? maybe there something not really right ?
P
Click to expand...
Click to collapse
I will post, but for me this is good enough others are drawing in 200-2000 milliseconds
The SDK part:
Code:
@Override
public void onDrawFrame(GL10 gl) {
long start = System.currentTimeMillis();
LibJNIWrapper.rendererOnDrawFrame();
long end = System.currentTimeMillis();
//Log.e("Renderer", "onDrawFrame() took: "+ (end-start)+" millisec (1e-6)");
}
The related NDK part:
Code:
void renderer_on_draw_frame() //4
{
LOGE("renderer_on_draw_frame");
//copy
static float grey;
grey += 0.01f;
if (grey > 1.0f) {
grey = 0.0f;
}
glClearColor(grey, grey, grey, 1.0f);
checkGlError("glClearColor");
glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
checkGlError("glClear");
int i;
for (i = 0; i < CANDLES_COUNT; i++) {
//LOGE("chartengine rendering i= %d",i);
renderLine((candles[i].coloredSingleLine));
renderRectangle((candles[i].coloredSingleRectangle));
}
glFlush();
}
line rendering:
Code:
void renderLine(ColoredSingleLine* pColoredSingleLine) {
if (pColoredSingleLine == NULL) {
return;
}
//matrixTranslateM(mvpMatrix, rndX, rndY, 0);
//LOGE("###renderLine pColoredSingleLine %p\n",pColoredSingleLine);
glUseProgram(pColoredSingleLine->programColoredLine.program);
checkGlError("Line: glUseProgram");
// Enable a handle to the triangle vertices
glEnableVertexAttribArray(pColoredSingleLine->programColoredLine.a_position_location);
checkGlError("Line: glEnableVertexAttribArray");
// Prepare the triangle coordinate data
glVertexAttribPointer(pColoredSingleLine->programColoredLine.a_position_location, pColoredSingleLine->lineData.COORDS_PER_VERTEX_LINE, GL_FLOAT, GL_FALSE,
pColoredSingleLine->lineData.vertexStride, pColoredSingleLine->lineData.vertices);
checkGlError("Line: glVertexAttribPointer");
// Set color for drawing the triangles
glUniform4fv(pColoredSingleLine->programColoredLine.u_color_location, 1, pColoredSingleLine->lineData.color_rgba);
checkGlError("Line: glUniform4fv");
// Apply the projection and view transformation
glUniformMatrix4fv(pColoredSingleLine->programColoredLine.u_mvp_matrix_location, 1, GL_FALSE, pColoredSingleLine->lineData.mvpMatrix);
checkGlError("Line: glUniformMatrix4fv");
glLineWidth(pColoredSingleLine->lineData.lineWidth);
// Draw the line
glDrawArrays(GL_LINES, 0, pColoredSingleLine->lineData.vertexCount); // (GLenum mode, GLint first, GLsizei count);
checkGlError("Line: glDrawArrays"); // GL_INVALID_ENUM
//GL_INVALID_ENUM is generated if mode is not an accepted value.
//GL_INVALID_ENUM is generated if type is not GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT.
GLint error = glGetError();
if (error == GL_OUT_OF_MEMORY) {
LOGE("Out of Video memory error...congrats...is your device a stone ?");
}
// Disable vertex array
glDisableVertexAttribArray(pColoredSingleLine->programColoredLine.a_position_location);
}
and the rectangle:
Code:
void renderRectangle(ColoredSingleRectangle* pColoredSingleRectangle) {
if (pColoredSingleRectangle == NULL) {
return;
}
//matrixTranslateM(mvpMatrix, rndX, rndY, 0);
glUseProgram(pColoredSingleRectangle->programColoredRectangle.program);
checkGlError("Rectangle: glUseProgram");
// Enable a handle to the triangle vertices
glEnableVertexAttribArray(pColoredSingleRectangle->programColoredRectangle.a_position_location);
checkGlError("Rectangle: glEnableVertexAttribArray");
// Prepare the triangle coordinate data
glVertexAttribPointer(pColoredSingleRectangle->programColoredRectangle.a_position_location, pColoredSingleRectangle->rectangleData.COORDS_PER_VERTEX_RECTANGLE, GL_FLOAT, GL_FALSE,
pColoredSingleRectangle->rectangleData.vertexStride, pColoredSingleRectangle->rectangleData.vertices);
checkGlError("Rectangle: glVertexAttribPointer");
// Set color for drawing the triangles
glUniform4fv(pColoredSingleRectangle->programColoredRectangle.u_color_location, 1, pColoredSingleRectangle->rectangleData.color_rgba);
checkGlError("Rectangle: glUniform4fv");
// Apply the projection and view transformation
glUniformMatrix4fv(pColoredSingleRectangle->programColoredRectangle.u_mvp_matrix_location, 1, GL_FALSE, pColoredSingleRectangle->rectangleData.mvpMatrix);
checkGlError("Rectangle: glUniformMatrix4fv");
// Draw the square
glDrawElements(GL_TRIANGLES, NELEMS(pColoredSingleRectangle->rectangleData.drawOrder), GL_UNSIGNED_SHORT, pColoredSingleRectangle->rectangleData.drawOrder); // GL_INVALID_ENUM on Galaxy note
checkGlError("Rectangle: glDrawElements"); // GL_INVALID_ENUM
//GL_INVALID_ENUM is generated if mode is not an accepted value.
//GL_INVALID_ENUM is generated if type is not GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT.
GLint error = glGetError();
if (error == GL_OUT_OF_MEMORY) {
LOGE("Out of Video memory error...congrats...is your device a stone ?");
}
// Disable vertex array
glDisableVertexAttribArray(pColoredSingleRectangle->programColoredRectangle.a_position_location);
}
At any benchmarks my fps is bellow 12, while other devices has 30 or 50 fps. Believe me not my device has the best CPU + GPU by far:
some output from on old code:
Code:
printGLString("Version", GL_VERSION);
printGLString("Vendor", GL_VENDOR);
printGLString("Renderer", GL_RENDERER);
printGLString("Extensions", GL_EXTENSIONS);
....
void printGLString(const char *name, GLenum s) {
const char *v = (const char *) glGetString(s);
LOGE("GL %s = %s\n", name, v);
}
// ### GT-N8000 ### Galaxy note 10" - GL Renderer = Mali-400 MP
// GL_EXT_debug_marker
// GL_OES_texture_npot
// GL_OES_compressed_ETC1_RGB8_texture
// GL_OES_standard_derivatives
// GL_OES_EGL_image
// GL_OES_depth24
// GL_ARM_rgba8
// GL_ARM_mali_shader_binary
// GL_OES_depth_texture
// GL_OES_packed_depth_stencil
// GL_EXT_texture_format_BGRA8888
// GL_EXT_blend_minmax
// GL_OES_EGL_image_external
// GL_OES_EGL_sync
// GL_OES_rgb8_rgba8
// GL_EXT_multisampled_render_to_texture
// GL_EXT_discard_framebuffer
// ### THL V8S - GL Renderer = PowerVR SGX 544MP
// GL_EXT_debug_marker
// GL_OES_rgb8_rgba8
// GL_OES_depth24
// GL_OES_vertex_half_float
// GL_OES_texture_float
// GL_OES_texture_half_float
// GL_OES_element_index_uint
// GL_OES_mapbuffer
// GL_OES_fragment_precision_high
// GL_OES_compressed_ETC1_RGB8_texture
// GL_OES_EGL_image
// GL_OES_EGL_image_external
// GL_OES_required_internalformat
// GL_OES_depth_texture
// GL_OES_get_program_binary
// GL_OES_packed_depth_stencil
// GL_OES_standard_derivatives
// GL_OES_vertex_array_object
// GL_OES_egl_sync
// GL_OES_texture_npot
// GL_EXT_multi_draw_arrays
// GL_EXT_texture_format_BGRA8888
// GL_EXT_discard_framebuffer
// GL_EXT_shader_texture_lod
// GL_IMG_shader_binary
// GL_IMG_texture_compression_pvrtc
// GL_IMG_texture_compression_pvrtc2
// GL_IMG_texture_npot
// GL_IMG_texture_format_BGRA8888
// GL_IMG_read_format
// GL_IMG_program_binary
// GL_IMG_uniform_buffer_object
// GL_IMG_multisampled_render_to_texture
materials
OK!
i know why it's so slow, you practically draw something 300x per frame and it doesn't really matter if it has 2 trinagles or 300 per one call.
300x setup shader per frame is almost a limit for slower(not slow) devices.
Main issues:
1) do not ever call glGetError when not debugging/running debug build - it makes pipeline stall (pipeline stops and waits until all commands are executed)
2) since you have 100 lines - and using for all of them same program, why not to group them in one array ?
2 solutions
-----------------
A)
= you are not using vertex buffers - so
1) create temporary memory and pre-transform all lines/triangles into one array - will be much faster
2) setup shader once + set uniforms
3) setup attributes - start of temporary array you created (every call - believe me, it will be faster, good practice is create array on stack, but beware of overflow - but for 300 lines is practically impossible)
3) call one draw call for all lines/triangles at once
B) even faster solution (fake instancing) - this is really fast
= create vertex buffer with data (and now create this as real VBO !)
- and not with only 1 instance of line, but with reasonable count - for instance 300 (fake instancing) - 300x line data repeated,
- in tex.x,y (for instance) - set index 0.299 -> x = (float(index % 256) / 256.0f ) y = ( (index & (~255)) / 256.0 ) - using lowp vec2 inTex; attribute
= in shader:
- create uniform array with coordinates for instance uniform mediump vec3 positions[300];
- in vertex part - something like this
gl_Position.xyz = inPosition.xyz + positions[(int) ((inTex.x * 256.0) + (inTex.y * 65536.0)) ];
1) use shader
2) fill array with positions and set it to uniform
3) set attributes
4) draw - and according to situation change count of elements drawn
if you need draw more than 300 lines, enlarge array OR just do more calls this time this is getting efficient
But i suppose 1st solution will be more than enough.
Cheers.
P.
Petr Sovis said:
OK!
i know why it's so slow, you practically draw something 300x per frame and it doesn't really matter if it has 2 trinagles or 300 per one call.
300x setup shader per frame is almost a limit for slower(not slow) devices.
Main issues:
1) do not ever call glGetError when not debugging/running debug build - it makes pipeline stall (pipeline stops and waits until all commands are executed)
2) since you have 100 lines - and using for all of them same program, why not to group them in one array ?
2 solutions
-----------------
A)
= you are not using vertex buffers - so
1) create temporary memory and pre-transform all lines/triangles into one array - will be much faster
2) setup shader once + set uniforms
3) setup attributes - start of temporary array you created (every call - believe me, it will be faster, good practice is create array on stack, but beware of overflow - but for 300 lines is practically impossible)
3) call one draw call for all lines/triangles at once
B) even faster solution (fake instancing) - this is really fast
= create vertex buffer with data (and now create this as real VBO !)
- and not with only 1 instance of line, but with reasonable count - for instance 300 (fake instancing) - 300x line data repeated,
- in tex.x,y (for instance) - set index 0.299 -> x = (float(index % 256) / 256.0f ) y = ( (index & (~255)) / 256.0 ) - using lowp vec2 inTex; attribute
= in shader:
- create uniform array with coordinates for instance uniform mediump vec3 positions[300];
- in vertex part - something like this
gl_Position.xyz = inPosition.xyz + positions[(int) ((inTex.x * 256.0) + (inTex.y * 65536.0)) ];
1) use shader
2) fill array with positions and set it to uniform
3) set attributes
4) draw - and according to situation change count of elements drawn
if you need draw more than 300 lines, enlarge array OR just do more calls this time this is getting efficient
But i suppose 1st solution will be more than enough.
Cheers.
P.
Click to expand...
Click to collapse
Thanks
When I wrote I saw the glerror maybe it will slow down a bit.
Since I am coming from an object oriented development environment it was designed on that way...
The candle: line + triangle can have other data too. Maybe need to keep elsewhere the data...
The last candle line and rectangle and his color can change almost at each draw method: just 1 of the 4 params will nort change.
When the last candle is closed a new one need to be staeted
In this case needs to. Shift to left all other candles. Maybe for this I am keeping in separate methods.
I thought the shader setup is done in other part at least there I am getting the pointer to they. On surface changed/ created - I am not at PC now.
Text with price + time scale should be with a texture to a rectangle?
I will reply inline:
matheszabi said:
Thanks
When I wrote I saw the glerror maybe it will slow down a bit.
Since I am coming from an object oriented development environment it was designed on that way...
Click to expand...
Click to collapse
Object development has nothing to do with this , glGetError is NOT a function to retrieve error status from GL functions, its for debugging purposes only. Its commonly used as: (simple form)
#ifdef _DEBUG
#define CHECKGL(x) x; assert(glGetError() == GL_NO_ERROR)
#else
#define CHECKGL(x) x
#endif
CHECKGL( glUniform4f(.... .) );
or still very fast
#define CHECKGL(x) x; if (globalDebugGL) { assert(glGetError() == GL_NO_ERROR); }
matheszabi said:
Thanks
The candle: line + triangle can have other data too. Maybe need to keep elsewhere the data...
The last candle line and rectangle and his color can change almost at each draw method: just 1 of the 4 params will nort change.
When the last candle is closed a new one need to be staeted
In this case needs to. Shift to left all other candles. Maybe for this I am keeping in separate methods.
Click to expand...
Click to collapse
Again - preparing something to vertex buffer is 100x faster than calling gluseProgram, gluniform and then draw call.
Different values per "candle": you can change (per candle) color, position, tex coords, and another values - to max 16 vec4 attributes per vertex in vertex buffer.
just for your imagination what does exactly glUniform: it recompiles and rebuilds shader with new values. It's not fast at all. So drawing 2 triangles with new shader setup (different uniform values) is not very smart. You have only 800-1000 such operations per frame tops. New card can handle much more. Look for term "draw call batching" to learn more. Unity's main feature.
Just imagine, even chip in your phone can easily draw 20 textured MTris per sec and you draw just few thousands and it's sweating.
Very nice article about GLES 2.0 from apple - google for "OpenGL ES Design Guidelines" most of it is true on android as well
matheszabi said:
Thanks
I thought the shader setup is done in other part at least there I am getting the pointer to they. On surface changed/ created - I am not at PC now.
Text with price + time scale should be with a texture to a rectangle?
Click to expand...
Click to collapse
That differs according to your situation.
- Is price/time always same ? (texture)
- it's changing per frame, (prerender texture)
- it's changing per "candle" ? - I posted articles about text in gl apps in the last post.
I thing you can choose your way !
Cheers
P.
Thanks for answer.
Petr Sovis said:
That differs according to your situation.
- Is price/time always same ? (texture)
- it's changing per frame, (prerender texture)
- it's changing per "candle" ? - I posted articles about text in gl apps in the last post.
Click to expand...
Click to collapse
Price/time is the same until: the user press a button, than will change the time ( From To values) and collecting data will result a min price and a max price. So the price probably will change at that button event, but not all the time.
Also the last candle price value is "moving" at least the close value, but an move the min or max value too, which can be the min or the max of the whole chart, on those rare situations need to change the coordinate system too. Can be used here a trick as it is changing and it will add +20% so what not need to change on each tick (frame)
233528246055
matheszabi said:
Thanks for answer.
Price/time is the same until: the user press a button, than will change the time ( From To values) and collecting data will result a min price and a max price. So the price probably will change at that button event, but not all the time.
Also the last candle price value is "moving" at least the close value, but an move the min or max value too, which can be the min or the max of the whole chart, on those rare situations need to change the coordinate system too. Can be used here a trick as it is changing and it will add +20% so what not need to change on each tick (frame)
Click to expand...
Click to collapse
I would definitely use rendering text technique I already posted. Its very fast (when implemented properly) and you can "print" whatever you want.
One of the following
bitmap fonts: (more content preparations - you need to prepare texture for each font)
-------------------
font bitmap creator: google: angelcode bmfont
+ sample: google: "nehe 2d_texture_font"
freetype implementation: (easier use - free type can generate font you want - also very fast)
-------------------------------------
it's possible to compile it with ndk - i use it and it's simple
google: freetype
and code for starters: google: "nehe freetype_fonts_in_opengl"
Cheers
P.