[Dev] EGL OpenGL ES

Carsten Haitzler c.haitzler at samsung.com
Mon Nov 2 02:23:31 GMT 2015

On Mon, 02 Nov 2015 11:54:05 +1000
Peter <jini at zeus.net.au> wrote:

> On 2/11/2015 11:28 AM, Carsten Haitzler wrote:
> > On Mon, 02 Nov 2015 11:21:47 +1000
> > Peter<jini at zeus.net.au>  wrote:
> >
> >> On 2/11/2015 9:41 AM, Carsten Haitzler wrote:
> >>> On Mon, 02 Nov 2015 09:24:23 +1000
> >>> Peter<jini at zeus.net.au>   wrote:
> >>>
> >>>> Is there a platform independant way of obtaining a Window and
> >>>> binding the EGL display to it without using EFL on Tizen?
> >>>>
> >>>> Is there a possiblity of Tizen supporting OpenKODE from Khronos
> >>>> in the future?
> >>> no. evas_gl replaces egl. it's done this way because there are so
> >>> many other things you want to use the widget infrastructure for
> >>> like indicator, kbd handling (eg sizing content to move out of
> >>> the way of the kbd) etc. and if you use evas_gl you can merge
> >>> both ui, widgets gl api.
> >>>
> >>> you simply need to change the egl parts (it's actually less work
> >>> using elm_glview than using egl - by far) and ensure your
> >>> rendering all happens in the render callback.
> >>>
> >> Carsten,
> >>
> >> Sounds good for creating a new application.
> >>
> >> I was investigating the work required to port an existing
> >> application.
> >>
> >> I noticed the EGL and GLES libraries exist on the tizen platform
> >> emulator.
> > yes - but you can't use them if you ever want to ship/distribute
> > your app. platform components only as they can change to move
> > display systems.
> >
> >> I was thinking of writing a wrapper library, that implements
> >> GLES2.0 around evas_gl.   A Tizen application has it's own lib
> >> directory, if I install the wrapper library into this directory,
> >> will it be resolved instead of the system GLES libraries?
> > i ... don't know actually. i do know that evas_gl and egl are not an
> > exact 1:1 match  and there are other things like NO swapbuffers so
> > you structure code differently.
> >
> > you are best off restructuring the egl code and isolating it in a
> > porting layer etc.
> >
> >> Thanks,
> >>
> >> Peter.
> >
> Thank you Carsten,
> Ignoring the display layer for a moment, the underlying system is
> Linux, I was going to bundle an Embedded JVM with the application
> (written in Java) using JOGL - Java Open GL bindings.
> Java has JNI which allows it to call C libraries and be invoked by C
> code.
> It would be nice if Tizen supported Java as well, don't know if there 
> are any plans in future to do so?

OK time to clarify a few things from a 3rd party developer perspective.
To save you time and ensure we're on the same page:

Tizen is a locked-down sandboxed OS in its reality shipped on actual
commercially available products. It COULD have been like "Linux" (i.e.
GNU/Linux distributions with a regular permission model, display
system, middleware etc.) but has chosen not to be and diverge fairly
significantly (as opposed to Android which just used a Linux kernel and
then built an entirely different OS on top). I quote that "Tizen is to
be as secure or more secure than iOS". Of course that means locking it
down so only the vendor has control.

It has moved further and further away from being Linux over time and
Java is not supported by Tizen. There are currently no plans to do so.
If it's not supported then it's "your job". And it's your job to do it
within the limits set.

So for an app, it's HTML5 with the Tizen web runtime or native with C
APIs (you can use C++ too for your app - your system interface is C
though). You use JUST the C APIs allowed and you cannot use one single
library or function symbol more than that or your app will never be
distributable or installable by anyone else. It'll be nothing more than
a local toy. Apps are checked for libraries linked and symbols accessed
from those libraries and are rejected at the appstore level if they use
any API not documented on tizen.org as a public API.

As a developer you get no root access on any device and devices are
locked down to the point of needing certificate signed by the
manufacturer (e.g. Samsung) to get permission to place applications
(regular ones) on your own device in front of you. That certificate I
think is valid for that device only and no others. Certificates are
manually approved last I knew. So this doesn't get you any extra
permissions other than permission to load app pkgs directly on the
device you have without going through the store to do so.

Oh and bootloaders only allow signed kernels - at least from the z3
onwards. Queue chain of trust spiel here.

So if you've gotten to this point by now being able to finally run
something on the device in front of you, you are limited only to the
APIs above. You must port the entire JVM and it's libraries yourself and
ensure it requires nothing beyond these APIs. Yes - you would have to
ship that JVM embedded with your app after ensuring this. You could
ensure that that layer uses the appropriate GL API sets in Tizen.

If you want to do platform development and build your own Tizen
devices and products, then you can do whatever you like - you have
root and ship software on your device so no one can stop you. I was
assuming for now you are aiming for "3rd party dev" as above on devices
available commercially.

More information about the Dev mailing list