Android port

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Android port

Tim Schmidt

Apologies if this has been asked before.

I hear that porting Qt applications to android is a surprisingly easy affair.  With newer tablets having 1280x800 screens, multi-core ghz cpus, and 1gb+ ram, they should even be capable of running such a port productively.

Ideas?  Plans?  Anyone willing to take a stab at it?

--tim

Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher
I took a look at it a while ago. Qt is available for android, and there is a version of boost floating around out that there for Android. The other dependencies would need to be compiled with the Android NDK. If I remember right, I stepped away from the project due to issues with boost.
I'll take another stab at this soon, I think I have a privileged perspective on the subject, having spent a lot of time figuring out how to cross-compile for Windows from Unix. I'll let you know how I get on.
-Brad

On Thu, Jan 12, 2012 at 1:51 PM, Tim Schmidt <[hidden email]> wrote:

Apologies if this has been asked before.

I hear that porting Qt applications to android is a surprisingly easy affair.  With newer tablets having 1280x800 screens, multi-core ghz cpus, and 1gb+ ram, they should even be capable of running such a port productively.

Ideas?  Plans?  Anyone willing to take a stab at it?

--tim


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Android port

Tim Schmidt

On Jan 12, 2012 5:21 PM, "Brad Pitcher" <[hidden email]> wrote:
>
> I took a look at it a while ago. Qt is available for android, and there is a version of boost floating around out that there for Android. The other dependencies would need to be compiled with the Android NDK. If I remember right, I stepped away from the project due to issues with boost.
> I'll take another stab at this soon, I think I have a privileged perspective on the subject, having spent a lot of time figuring out how to cross-compile for Windows from Unix. I'll let you know how I get on.
> -Brad

Good to know!  I'm very interested in your progress, and interested in testing anything you come up with!

--tim

Reply | Threaded
Open this post in threaded view
|

Re: Android port

donbright
OpenSCAD requires the following

eigen2
GMP
MPFR
Boost
CGAL
OpenCSG
QT

I have created 'hello world' programs for eigen2, GMP, MPFR, and
Boost, but never made it to CGAL or OpenCSG. You can find them here if
interested:

https://github.com/donbright/

There are many ways to set up cross-compilation, my way is probably
not the best. Many other people have also done work on android with
boost, eigen, gmp, and mpfr

CGAL, I am not so sure about.

CGAL's main problem is that it's compilation requires the running of a
'test suite' - i.e. during the build process, it builds a lot of
mini-programs, runs them, and reads the results back, and uses those
results to set flags for the build. For this to work in a
cross-compilation environment, you need to instead cross-compile the
little mini programs, transfer them to the target platform, run them,
then transfer the results back. Then you need to get CGAL's build
scripts to read those results in from a file.

I'm also guessing that CGAL might have issues with
CGAL-3.x/include/CGAL/FPU.h, but I'm not sure.

As for OpenCSG, well, it basically requires offscreen GL Framebuffer
Objects, which Im pretty sure are not a part of OpenGL ES 1.0, so
anything below Android 2.2 is not going to work.

Another problem is that the Android Emulator does not work with OpenGL
ES 2.0, so you (currently, Jan 2012) have to have an android phone if
you want to really test any OpenGL ES 2.0 programs.

Also, porting OpenSCAD's regression tests to android is a problem. Are
you going to run the whole thing - ctest, python, Imagemagic, etc, all
on android? It might be easier to just simply run the openscad test
program on android, and transfer the input and output files back and
forth through 'adb', rather than trying to run the whole mess on
android itself.

This might not be too hairy - we can already run the Windows
regression tests from inside of Linux, without needing Imagemagick or
Python or Ctest to be installed inside of Wine.

Good Luck to whoever tries this.

-DB


On Thu, Jan 12, 2012 at 5:08 PM, Tim Schmidt <[hidden email]> wrote:

> On Jan 12, 2012 5:21 PM, "Brad Pitcher" <[hidden email]> wrote:
>>
>> I took a look at it a while ago. Qt is available for android, and there is
>> a version of boost floating around out that there for Android. The other
>> dependencies would need to be compiled with the Android NDK. If I remember
>> right, I stepped away from the project due to issues with boost.
>> I'll take another stab at this soon, I think I have a privileged
>> perspective on the subject, having spent a lot of time figuring out how to
>> cross-compile for Windows from Unix. I'll let you know how I get on.
>> -Brad
>
> Good to know!  I'm very interested in your progress, and interested in
> testing anything you come up with!
>
> --tim
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: Android port

Triffid Hunter
It just occurred to me that it could be possible to set up a chroot on an android so we have a more sensible base layout.. I'm certain that would help!
Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher
In reply to this post by donbright
CGAL's main problem is that it's compilation requires the running of a
'test suite' - i.e. during the build process, it builds a lot of
mini-programs, runs them, and reads the results back, and uses those
results to set flags for the build. For this to work in a
cross-compilation environment, you need to instead cross-compile the
little mini programs, transfer them to the target platform, run them,
then transfer the results back. Then you need to get CGAL's build
scripts to read those results in from a file.

For mingw-cross-env, there is a patch which includes the results for all the tests (http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/899eb3105abf/src/cgal-1-fixes.patch#l29) so that should be easy to reuse. The results to the tests may not be technically accurate, but they allow the build to proceed.
 
Another problem I ran into with CGAL and OpenCSG is all the OpenGL stuff needs to be ported to OpenGL ES. From what I understand these are not trivial changes. Do you have experience with this Don? Any pointers?

Thank you very much for the detailed write-up, it's very helpful.
-Brad
Reply | Threaded
Open this post in threaded view
|

Re: Android port

Tim Schmidt
Possibly of interest:
http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/

The article compares PulseAudio to Android's native Audioflinger sound
server.  The author discusses porting PulseAudio, and links to several
useful-looking bits, like androgenizer (
http://cgit.collabora.com/git/user/derek/androgenizer.git/ ) which
converts autotools projects to android-friendly makefiles.

--tim

Reply | Threaded
Open this post in threaded view
|

Re: Android port

kintel
Administrator
In reply to this post by Brad Pitcher
On Jan 17, 2012, at 01:12 AM, Brad Pitcher wrote:
>  
> Another problem I ran into with CGAL and OpenCSG is all the OpenGL stuff needs to be ported to OpenGL ES. From what I understand these are not trivial changes. Do you have experience with this Don? Any pointers?
>
I'm considering rewriting the OpenGL stuff to use an external library for the actual rendering. Then all GL calls should be encapsulated and if the underlying library supports ES, it would be "automatically" supported.
Open Scenegraph is a bit overkill. I'm planning to take a glance at http://www.visualizationlibrary.org
Any other suggestions would be welcome.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher
I'm considering rewriting the OpenGL stuff to use an external library for the actual rendering. Then all GL calls should be encapsulated and if the underlying library supports ES, it would be "automatically" supported.
Open Scenegraph is a bit overkill. I'm planning to take a glance at http://www.visualizationlibrary.org
Any other suggestions would be welcome.

You're not saying you'll remove CGAL and OpenCSG as dependencies are you? The problem I'm having is with those libraries. They use all sorts of OpenGL stuff that isn't part of OpenGL ES, so both libraries would require significant changes. 
Reply | Threaded
Open this post in threaded view
|

Re: Android port

Whosawhatsis
It's my understanding that CGAL doesn't use OpenGL at all. It generates a mesh that is subsequently rendered using OpenGL, and rendering a mesh in OpenGL should use only the most basic features that are in all implementations.

On Tuesday, January 17, 2012 at 1:02 PM, Brad Pitcher wrote:

I'm considering rewriting the OpenGL stuff to use an external library for the actual rendering. Then all GL calls should be encapsulated and if the underlying library supports ES, it would be "automatically" supported.
Open Scenegraph is a bit overkill. I'm planning to take a glance at http://www.visualizationlibrary.org
Any other suggestions would be welcome.

You're not saying you'll remove CGAL and OpenCSG as dependencies are you? The problem I'm having is with those libraries. They use all sorts of OpenGL stuff that isn't part of OpenGL ES, so both libraries would require significant changes. 
_______________________________________________
OpenSCAD mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher
It's my understanding that CGAL doesn't use OpenGL at all. It generates a mesh that is subsequently rendered using OpenGL, and rendering a mesh in OpenGL should use only the most basic features that are in all implementations.

CGAL refuses to use Qt4 without it and the build falls back to Qt3. Digging into the code it looks like it's because it uses QGLWidget for something.
Reply | Threaded
Open this post in threaded view
|

Re: Android port

Giles Bathgate-2

I think you can build CGAL without the QT dependency the examples use QT4/3 for the UI but I think you can optionally compile it without these examples.

On Jan 17, 2012 9:16 PM, "Brad Pitcher" <[hidden email]> wrote:
It's my understanding that CGAL doesn't use OpenGL at all. It generates a mesh that is subsequently rendered using OpenGL, and rendering a mesh in OpenGL should use only the most basic features that are in all implementations.

CGAL refuses to use Qt4 without it and the build falls back to Qt3. Digging into the code it looks like it's because it uses QGLWidget for something.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher

I think you can build CGAL without the QT dependency the examples use QT4/3 for the UI but I think you can optionally compile it without these examples.

Ahh, I see, that's great! So the main problem is OpenCSG, which uses OpenGL and GLEW all over the place, though it looks like the work has been done to make GLEW compatible with OpenGL ES:
https://code.launchpad.net/~rsalveti/linaro-graphics-misc/glew-es-core-trunk

Nearly all the pieces are in place...
Reply | Threaded
Open this post in threaded view
|

Re: Android port

kintel
Administrator
In reply to this post by Brad Pitcher
On Jan 17, 2012, at 22:02 PM, Brad Pitcher wrote:

> I'm considering rewriting the OpenGL stuff to use an external library for the actual rendering. Then all GL calls should be encapsulated and if the underlying library supports ES, it would be "automatically" supported.
> Open Scenegraph is a bit overkill. I'm planning to take a glance at http://www.visualizationlibrary.org
> Any other suggestions would be welcome.
>
> You're not saying you'll remove CGAL and OpenCSG as dependencies are you? The problem I'm having is with those libraries. They use all sorts of OpenGL stuff that isn't part of OpenGL ES, so both libraries would require significant changes.

As others pointed out, CGAL is easy. Also, the actual object rendering in OpenCSG is easy to port.
The hard part is the OpenGL tricks which OpenCSG is doing.
Perhaps the best way would be to write an ES-compatible "backend" for OpenCSG. I'm sure that would be interesting for the OpenCSG developer(s) to pursue as well.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher
In reply to this post by kintel
I'm considering rewriting the OpenGL stuff to use an external library for the actual rendering. Then all GL calls should be encapsulated and if the underlying library supports ES, it would be "automatically" supported.
Open Scenegraph is a bit overkill. I'm planning to take a glance at http://www.visualizationlibrary.org
Any other suggestions would be welcome.


I'm not sure if this is exactly the same kind of thing, but have you looked at OpenFrameworks?
http://www.openframeworks.cc

They support OpenGL, GLEW, GLUT, libtess2, and cairo for graphics and it seems they take great effort to make everything extremely cross-compatible. From http://www.openframeworks.cc/about/:

"Right now we support five operating systems (Windows, OSX, Linux, iOS, Android) and four IDEs (XCode, Code::Blocks, and Visual Studio and Eclipse)."
Reply | Threaded
Open this post in threaded view
|

Re: Android port

kintel
Administrator
On Jan 19, 2012, at 00:55 AM, Brad Pitcher wrote:

> I'm not sure if this is exactly the same kind of thing, but have you looked at OpenFrameworks?
> http://www.openframeworks.cc
>
Open Framework is SDL-based and provide thin wrappers for misc. underlying libraries.
I wouldn't use the framework itself, but they might be using something interesting on the 3D side.
I haven't looked into it though.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Android port

Florian Kirsch
In reply to this post by kintel

> > You're not saying you'll remove CGAL and OpenCSG as dependencies are
> > you? The problem I'm having is with those libraries. They use all
> > sorts of OpenGL stuff that isn't part of OpenGL ES, so both
> > libraries would require significant changes.
>
> As others pointed out, CGAL is easy. Also, the actual object rendering
> in OpenCSG is easy to port.
> The hard part is the OpenGL tricks which OpenCSG is doing.
> Perhaps the best way would be to write an ES-compatible "backend" for
> OpenCSG. I'm sure that would be interesting for the OpenCSG
> developer(s) to pursue as well.

Probably. Actually we are talking about OpenGL ES 2.0 here, right? OpenGL ES 1.1 would require yet a different port, as far as I see it.

Florian




--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Reply | Threaded
Open this post in threaded view
|

Re: Android port

Brad Pitcher

Probably. Actually we are talking about OpenGL ES 2.0 here, right? OpenGL ES 1.1 would require yet a different port, as far as I see it.


Yeah, I'm not familiar with them but I don't see any reason not to use the latest. Probably easier and no sense in going back in time.