Use OpenGL

[GoogleCodeExporter]

Use OpenGL for drawing.

Original issue reported on code.google.com by taipanro...@gmail.com on 24 Jan 2010 at 8:56

[GoogleCodeExporter]

Original comment by taipanro...@gmail.com on 18 Apr 2010 at 7:40

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This gets my vote, as it would presumably help make the port future proof; 
would it
remove the need for a custom NDK?

Original comment by sse...@gmail.com on 19 Apr 2010 at 1:59

[GoogleCodeExporter]

Yes and No.
Currently to compile Qt with almost all modules (Script, Quick UI and Webkit) 
for
android you need only a NDK with stl support. Qt modules don't call any 
unofficial
APIs. So if you don't need Script, Quick UI and Webkit you CAN compile and use 
QT
with official NDK.

I'll be forced to call some unofficial APIs when I'll port Multimedia module,
because google don't give nothing better.

Original comment by taipanro...@gmail.com on 20 Apr 2010 at 3:32

[GoogleCodeExporter]

Is there a chance to report bugs against Android NDK to be able to support 
QtMultimedia?

Original comment by ismail.d...@gmail.com on 2 May 2010 at 7:51

[GoogleCodeExporter]

I don't know, there are a lot of requests on this topic on android-ndk mail 
list, but
it seems nobody care about them.

What I can tell you, QtMultimedia will be ported with or without official 
support.

Original comment by taipanro...@gmail.com on 4 May 2010 at 2:30

[GoogleCodeExporter]

Good to hear that!

Original comment by ismail.d...@gmail.com on 4 May 2010 at 2:34

[GoogleCodeExporter]

what exactly do you mean by Quick UI?

Original comment by ahmad.mu...@gmail.com on 10 Jun 2010 at 8:43

[GoogleCodeExporter]

@ahmad.mushtaq : See http://blog.qt.nokia.com/2010/02/15/meet-qt-quick/

Original comment by ismail.d...@gmail.com on 10 Jun 2010 at 8:46

[GoogleCodeExporter]

so i can use the QtGui/Graphics view frame work with the official ndk if i 
avoid Script, Quick UI and Webkit ?

Original comment by ahmad.mu...@gmail.com on 11 Jun 2010 at 5:40

[GoogleCodeExporter]

Yes.

Original comment by taipanro...@gmail.com on 11 Jun 2010 at 8:01

[GoogleCodeExporter]

Does this help in avoiding using a custom SDK: 

http://www.anddev.org/viewtopic.php?p=29939

Original comment by ahmad.mu...@gmail.com on 14 Jun 2010 at 7:21

[GoogleCodeExporter]

I meant NDK

Original comment by ahmad.mu...@gmail.com on 14 Jun 2010 at 7:36

[GoogleCodeExporter]

  My first custom NDK contains the STLport, then I found Dmitry Moskalchuk's NDK (see http://www.crystax.net/android/ndk-r4.php) which, IMHO, is better and complete (my current NDK are based on Crystax's NDK).

Starting with 
http://qt.gitorious.org/~taipan/qt/android-lighthouse/commit/37f298c40ca19570f2c
2302f227323711c8478e9 I remove ~ all unofficial API calls, I use only OpenSSL 
which isn't in the official NDK, so if you don't need SSL you can safely use 
Dmitry Moskalchuk's NDK (this NDK use only official APIs, stl and other c++ 
stuff are compiled statically).

Original comment by taipanro...@gmail.com on 14 Jun 2010 at 8:19

[GoogleCodeExporter]

Hi. I've been trying to launch a couple of Qt OpenGL examples from 
android-lighthouse project on Android 2.1 and 2.2, but without success. 
Depending on the example, they either crash immediately or display the part of 
the UI, which is not in OpenGL and then exit. I have noticed that OpenGL 
initialization in QtApplication::loadApplication is commented out, but 
compiling the examples with this line also does not solve anything.

Could you comment a little on current OpenGL support from Qt? Do you know what 
still needs to be done to be able to use QtOpenGL module functionality under 
Android? Perhaps someone can provide some help with that, but it's very 
difficult to take up such a task without knowing current status of the problem.

Original comment by misanthr...@gmail.com on 23 Jun 2010 at 8:28

[GoogleCodeExporter]

I'm sorry for this inconvenient, unfortunately I don't have good news, I didn't 
manage to get any progress in this direction. This is my top priority issue. 
This days I'll try to give you more detail informations about current OpenGL 
support.

Thank you very much.

Original comment by taipanro...@gmail.com on 24 Jun 2010 at 8:21

[GoogleCodeExporter]

this should just stay an option, as there are some non GLed Android devices 
which do completly relie in ANdroids softrendering

apparently those devices are also very oft low powered on the CPU ending and 
thus native android performance should be a focus

Original comment by winroot...@gmail.com on 14 Aug 2010 at 2:27

[GoogleCodeExporter]

Any updates about the state of OpenGL in Android/Qt?   
Can we create an OpenGL context and draw opengl into it?
I don't need the entire UI to be drawn by OpenGL.   But I do need to render 
graphics with OpenGL...

thanks for any updates, and great work so far!

Original comment by kevin.me...@gmail.com on 3 Sep 2010 at 6:28

[GoogleCodeExporter]

I just wanted to say Android's latest NDK seems to have everything you now 
need.  EGL and OpenGLES are exposed, they've also included STLport.

http://developer.android.com/sdk/ndk/index.html

I think Google are listening well to the community ...

Original comment by ahmed.a....@gmail.com on 18 Dec 2010 at 9:40

[GoogleCodeExporter]

This is not helping me to much, the problem is when I have to create more 
OpenGL surfaces, currently you can't do it.

Original comment by taipanro...@gmail.com on 17 Jan 2011 at 6:03

[GoogleCodeExporter]

Is there any news regarding OpenGL support? Is there even an experimental code 
out there that does support OpenGL (even partially)?
Can anyone estimate how long before OpenGL support is complete?

Thanks,
Yaron

Original comment by yaronf...@gmail.com on 6 Apr 2011 at 10:05

[GoogleCodeExporter]

The problem with drawing everything via OpenGL is that it'll use the phone's 3D 
hardware.

Pro: Speed
Con: BATTERY

My battery doesn't exactly last a long time as is:  Evo 4G.

Original comment by mstorer3...@gmail.com on 27 Apr 2011 at 5:56

[GoogleCodeExporter]

I got a galaxy tab (7") and want to get Qt with opengl-support running.

First thing I did: 
I changed the build-env so it uses android-9 (which comes with opengl_ES2 and 
EGL)

What I really need is a accelerated QDeclarativeView (/QGraphicsView) via 
setViewport(new QGLWidget) ... so accelerating QWidget via '-graphicssystem 
opengl' is not in my requirement-list  (as this is still experimental anyway)

:)

... so far this crashes ... I guess because the default andriod-platform-plugin 
is based on fb_base (which is a QImage) ... 
Another symptom of the same cause is probably: hellogl_es2 stays black in the 
middle.

...and then found: src/plugins/platforms/android/mw
which eventually also built ... but is not running:
androidjnimain.cpp: setQtApplicationObject(JNIEnv* env)
prints: "Native registration unable to find class 
'com/nokia/qt/android/QtApplication'"

Not sure why this happens/what that means ... but I'm guess the crash afterward 
is caused by this.

I'm new to android ... but as a Troll I know Qt
... so maybe I can help/can be helped ;)

Greets
Thomas

Original comment by thomas.s...@nokia.com on 5 May 2011 at 4:53

[GoogleCodeExporter]

... ah and as a side note:
-graphicssystem opengl     is definitely not the golden way!

Having the raster graphicssystem is good enough for all practical 
qwidget-usecases.
(simple UIs, (setup)-dialogs, ...)

If you want nice graphics you gonna go with QGraphicsView/QDeclarativeView 
anyway.
-> use setViewport(new QGLWidget) to accelerate that.

Original comment by thomas.s...@nokia.com on 5 May 2011 at 4:59

[GoogleCodeExporter]

Hello Thomas,

I'd like to start with an introduction about (current) Android OpenGL 
limitations per application:
 - you can't create more than one OpenGL context.
 - you can't create more than one Window surface (SurfaceView), actually you can create more than one, but they are useless because you can't control their Z order.
 - you can create additionally Pixel buffer surfaces.

The problem is that Qt needs an OpenGL surface for every Top Level Widget (TLW).
I've discuss this situation with some friends (I'm not an OpenGL expert) and we 
found two possible solutions:
1. Using a pixmap or a pbuffer surface, for every TLW, make them textures and 
then compose them to a windows surface.
pro: - the user can do anything with that surface.
con: - the speed will be slow.

2. Using frame buffer objects, this is our favorite approach, the problem is 
that the current Qt OpenGL implementation needs to be changed (a lot).
pro: - probably is the fastest way to do it.
con: - only platforms >=5 supports OpenGL ES 2, android-4 platform has FBO 
support only via OpenGL extensions.
     - the user is a little bit limited.

   If we decide to go with option 1 then, we can combine raster and OpenGL rendering, but if we'll choose option 2 then everything must be paint using OpenGL, which IMHO should not be that bad, so because we didn't pick any options, any suggestion/solution is very appreciated.

I've removed OpenGL support some time ago, because it never worked, but if you 
want to give it a try, I'll add it to another branch.

BogDan.

Original comment by taipanro...@gmail.com on 6 May 2011 at 3:34

[GoogleCodeExporter]

Option:
0: Having one fullscreen opengl context for your e.g. QDeclarativeView would be 
good enough for a start. It's not a clean solution which should be called 
"ready to use", but for some hand-made demos/examples it should be good enough.
==> Yes I would like to give it a try @ OpenGL support.
But as I wrote, I've close to no experience with Android :)

Not sure about 1. and 2.  ... the opinion of someone who knows the 
graphicssystem of Qt better then me is required.

"can't create more than one Window surface"
Is this a know platform limitation/specification?

Original comment by thomas.s...@nokia.com on 6 May 2011 at 8:19

[GoogleCodeExporter]

  Option 0 doesn't seem to be very useful for all apps, because AFAIK most of them need more than one TLW for: a menu, a drop list, a dialog, etc.

> "can't create more than one Window surface"
> Is this a know platform limitation/specification?

Yes it is known platform limitation, check 
http://developer.android.com/reference/android/view/SurfaceView.html , 
http://groups.google.com/group/android-developers/browse_thread/thread/08e7df2e9
6a7973d , http://stackoverflow.com/questions/4521674/handling-two-surfaceviews 
, etc.

Original comment by taipanro...@gmail.com on 6 May 2011 at 8:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok I understand more about the problem now.

The problem with solution 2 is that you need to render everything in OpenGL in 
order to fill your FBO (at least that's the case on other platforms ... I think)

Option 1:
And as far as I understand it's no problem (or better required) to do the 
compositing with OpenGL ... You definitely don't want to compose on/with the 
CPU.
The really good thing about that is you can mix.
Rendering QWidgets for OpenGL is far(!) from being optimal.
The QPainter will invoke a lot(!) of opengl-state-changes which could ruins 
your performance.

I'm not sure but as I'm not a big fan of "-graphicssystem opengl" (aka. 
rendering everything with opengl) I'm in favor of Option 1
In addition to that I guess it requires less afford to get it running.

Original comment by thomas.s...@nokia.com on 6 May 2011 at 9:46

[GoogleCodeExporter]

Hmm after reading and experimenting a little bit ... I got some new 
ideas/theories and of course questions ;)

First of all I got a theory:
You can create more then one EGLContext, you just can't create more then on 
GLSurfaceView ... which means: only one EGLContext can render on-screen and 
that one has to render in it's own thread (via 
GLSurfaceView.Renderer.onDrawFrame()).

If I'm wrong with this theory, please correct me :)

If it's the case that I'm wrong: 
You can't have more then one surface (read pbuffer-surface vs. on-screen 
surface) in the same EGLContext, which would mean solution 1 is from the table.

If I'm right:
I think you have to have a least 2 egl-context because as far as I can read 
from various forum-posts it is not possible to use the context from 
GLSurfaceView in another thread then the one from 
GLSurfaceView.Renderer.onDrawFrame() 
=> We need another egl-context for the qt-gui-thread

No the question pops up (still only if I'm right with my theory):
Can you use FBO cross-egl-context?
All I always read is: "FBO doesn't require to be on it's own context like a 
pbuffer" ... but does this also mean that they "can't be on it's own context 
and still used by another context"?

Original comment by thomas.s...@nokia.com on 20 May 2011 at 2:09

[GoogleCodeExporter]

Any updates about the state of OpenGL in Android/Qt?
I have run several opengl examples, all opengl area is dark.
Does it means that it is currently sure not support OpenGl?
Thanks

Original comment by lingfan...@163.com on 25 May 2011 at 8:24

[GoogleCodeExporter]

Hi,all. 
I am very interesting to this problem because we are trying to use the android 
lighthouse with OpenGL for some projects. 
Can I get your emails? And my email is "cussyou@gmail.com". 
Many thanks!

Original comment by cuss...@gmail.com on 25 May 2011 at 10:43

[GoogleCodeExporter]

I'm currently working on a code merge of:
- android port
- eglfs (see src/plugins/platforms/eglfs 
(this means you can only have on fullscreen opengl-widget.
e.g. as a viewport for a QDeclarativeView)
- hellogl-es2 example from the SDK

So far the qt-opengl-paintengine can paint in a pbuffer and then I can blit 
with opengl es onto a GLSurfaceView ...

But this is far from being useful currently because updates are only partial 
(very broken display output!) ... right in this moment I'm onto this and when 
I've fixed this I'm willing to share my crappy code ;)

Longterm I'm planing to contribute this to the android-lighthouse project 
(maybe in another shape)

If any of you wants to do anything besides a fullscreen-QGLWidget (for 
QGraphicsView::setViewport) I guess you have to wait.

Original comment by thomas.s...@nokia.com on 25 May 2011 at 11:45

[GoogleCodeExporter]

Thank you thomas.
When will you republish the merge? 
We want to do some work to try the option 1 above as soon as possible.
Could you post a me copy of "src/plugins/platforms/eglfs". And my email is 
cussyou@gmail.com .
Many Thanks.

Original comment by cuss...@gmail.com on 26 May 2011 at 8:36

[GoogleCodeExporter]

Hi, thomas,
Is there any progress about the code merge?
Thanks

Original comment by lingfan...@163.com on 7 Jun 2011 at 1:34

[GoogleCodeExporter]

Yes, check experimental-eglfs branch

Original comment by taipanro...@gmail.com on 7 Jun 2011 at 6:30

[GoogleCodeExporter]

Great work! Thanks
When I run it, there is a link error, setupQtOpenGL and renderQtOpenGL have no 
implementations in QtApplication class.
If I commont these two method calls, there will be a black full screen exist.
It seems there is no error, but why just black full screen?
Is it a mistake?

Original comment by lingfan...@163.com on 8 Jun 2011 at 9:11

[GoogleCodeExporter]

Depending on what side they are missing:
- c++: Your linking against the wrong lib. For now I push libandroid-9.so as 
libandroid-8.so because I didn't wanted to dig to deep into the Java classes.
(There will be a better solution soon)
- Java: You are using the wrong Java files. Take a look at: 
AndroidEGLFS-IMPORTANT

Original comment by thomas.s...@nokia.com on 8 Jun 2011 at 1:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks!
I pushed libandroid-9.so as libandroid-8.so, but the link error is still there.
I know the setupQtOpenGL and renderQtOpenGL method is in eglfs module, but why 
not find them in libandroid-9?
Is there extra settings to compile libandroid-9.so?

Original comment by lingfan...@163.com on 9 Jun 2011 at 5:47

[GoogleCodeExporter]

Please pull and recompile again. It should work

Original comment by taipanro...@gmail.com on 9 Jun 2011 at 5:57

[GoogleCodeExporter]

hi,all
I have done some test about option 1.
1. draw all with gl to a pbuffer surface
2. use "glReadPixels" to read the pbuffer to a Qimage with format GL_RGBA
3. convert the Qimage into the ARGB format
I found it's too slow. Nearly all time are spend on the step 3.

I want to try that call "glReadPixels" with GL_RGB (QImage in RGB888), but it 
gives a opengl error 1282. :(

can you give me some methods to improve the speed ?
Many thanks.

Original comment by cuss...@gmail.com on 10 Jun 2011 at 7:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

checkout the code in 
https://qt.gitorious.org/~taipan/qt/android-lighthouse/commits/experimental-eglf
s

src/plugins/platforms/android/common/eglfs/
It's using off-screen pbuffers and glBindTexImage (==using a pbuffer as texture 
without copy it) to blit the pbuffer on-screen with opengl

glReadPixels would be something we could use if we want to use raster as a base 
and have some glcontext embedded. But this will never be any good in terms of 
performance.

The real thing would be rendering everything with opengl directly to the screen 
(without the pbuffer-blitting-step) ... BogDa is currently working on an 
egl-wrapper, as soon as this is ready we start working on that.

Original comment by thomas.s...@nokia.com on 10 Jun 2011 at 8:09

[GoogleCodeExporter]

I used convert codes like GLWidget::convertFromGLImage() in the file qgl.cpp.

Original comment by cuss...@gmail.com on 10 Jun 2011 at 8:29

[GoogleCodeExporter]

Note that Qt does have a QGLFramebufferObject class that uses FBOs.. maybe we 
could just use it for our window surfaces?

Original comment by tman...@gmail.com on 10 Jun 2011 at 11:26

[GoogleCodeExporter]

Any update on this? Wanting just a top level OpenGL window, and handle engine 
through Qt.

Original comment by TorisanK...@gmail.com on 15 Aug 2011 at 1:19

[GoogleCodeExporter]

Yes. It's merged into master
There are opengl-plugins for variose paltforms.

But they all have one limitation:
You only got one fullscreen surface!

This is only a problem for some QWidget based applications (e.g.: no drop-box, 
because a drop-box needs it's own surface)

If you're doing a fullscreen-QGraphcisView/QDeclarativeView application you're 
on the good side :)

Original comment by thomas.s...@nokia.com on 16 Aug 2011 at 8:18

[GoogleCodeExporter]

Awesome progress Thomas, I've managed to get something running and
displaying content on a Motorola Xoom with a hacked copy of the
experimental-eglfs-jw, however to do that I had to completely disable
ministro (I removed it from the QtActivity.java, and manually override what
platform .so was being used. Now I see that there is OpenGL stuff in the
main experimental branch, and
I'm trying to use that, however I can't seem to find out how to specify that
my app needs to use the androidGL variant of the platform plugin's or what
version to use.

Thanks in advance.

Matthew

Original comment by matthew....@gmail.com on 18 Aug 2011 at 3:42

[GoogleCodeExporter]

The experimental-eglfs-jw branch tripped me up, too. I'd recommend that that 
branch and experimental-eglfs be removed.

Matthew, OpenGL should be enabled by default on master/experimental. However I 
had to do some things to get my packages running. First, make sure you have a 
recent qt-creator (the branch I used was 2.3-stagging.) Then here's what I did 
to get Qmlshowcase running:

Changed TARGET on line 61 of qmlshowcase.pro from "./bin/qmlshowcase" to just 
"qmlshowcase"
The app was not finding the app library before I did this. Also, there seems to 
be a bug that is causing the build to stick that library in 
"<build-dir>/libs./bin/". It creates a new directory called "libs." instead of 
getting rid of the . or adding a slash before it. Removing the path from the 
target fixed this problem.

Added these lines to the top of startApp() in QtActivity.java:
        getIntent().putExtra("use_local_qt_libs", "true");
        getIntent().putExtra("load_local_libs", "plugins/platforms/android/libandroidGL-9.so");
Qt Creator is failing to start my application (presumably with the 
"use_local_qt_libs" intent set to true) when I have the option selected to 
deploy local libs. For some reason it says it's starting the app, and nothing 
happens on the Android end. (It does push the libs to the device just fine, 
however.) So I'm manually injecting the option.
Next, the app is not loading the Android plugin. I don't see any evidence of it 
trying. As a result I force it to load the androidGL-9 lib.

Of course I would check that you actually need to do these things on your end 
first.

Original comment by tman...@gmail.com on 18 Aug 2011 at 4:02

[GoogleCodeExporter]

If no one opposes I would delete following branches:
remotes/origin/experimental-eglfs
remotes/origin/experimental-eglfs-jw

They are merged back to master anyway.
... I know deleting branches is always controversial :)

Greets
Thomas

Original comment by thomas.s...@nokia.com on 19 Aug 2011 at 9:10