[Dev]   SDL support on Tizen

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Sat May 28 01:01:47 GMT 2016


On Sat, 28 May 2016 10:20:53 +1000 (AEST) Peter <jini at zeus.net.au> said:

> I started writing java bindings for Tizen (on github).  I was impressed by
> the object orientated nature of Enlightenment and how easy it is to hand
> craft java bindings for, following the inheritance hierarchy.  Tools that
> generate bindings don't do so well.

orly? everyone keeps going "efl is not oo! make it oo! (rewrite in c++ is what
they mean)". i keep saying oo is a concept independent of language. efl does do
things relatively oo-ish. it could be improved (and thats what all the eo infra
is for - now it looks REALLY oo with a single function for del/unref of every
single object and direct strict inheritance/milti-inheritance and more).

fyi - eolian should actually make it far easier to generate bindings. we
already auto generate bindings for lua, js and c++ directly from the
original .eo files for efl api. the .eo files are written at a high level
abstraction and eolian generates/maintains the c boilerplate and there are
various binding generators per one of the above languages. writing a generator
for java shouldn't be too hard considering all of the other languages we are
already handling. this means the core of efl remains c and there is a core c
api with the bindings sitting directly 1:1 on top of this handling reference
counting and more. considering the constraints of things like js and lua i
think java should be easy. once you have a generator then maintenance is over.
it's not just re-running it to pull out more api's into java whenever the
libraries update and add classes and methods. we already run the js, lua and c+
+ generators every time efl builds as part of the efl makefiles.

> JOGL and JOAL bindings already exist, but I can't get access to a native
> window on which to draw.

as below - you will have to re-bind and make jogl etc. compatible api on top of
elm_glview etc. it wouldn't be hard at all.

> What I'd like is a standard way to get a window (full screen) on which to
> draw using opengles.   Events can be used to gracefully get out of the way,
> suspend etc.  I need some kind of compatibility layer between JoGL and
> enlightenment to make it work.

technically with is possible, but it looks more like:

create window (elm_win), put elm_glview in win, show it, show win. done. now
your window is filled with a glview. there are associated properties of the
glview.

it's actually FAR LESS code than using egl/glx+native xlib or wayland for
example (as i've been doing this stuff for a long time... to do this RIGHT
takes a fair bit of code like getting visual and colormap right in x11). far far
less.

the glview can allow you to use gles2/3 or 1.1 api on it (there is a complete
gles set of api's in the evas_gl api struct). did you look at the glview
examples in elementary_test? if you enable direct rendering fyi ... you get
zero overhead support - no extra copies. the api funcs are almost all just
direct pass down except a few like scissor stuff etc. - there is even a helper
header that removed the need for glapi->func() and allows just the old func()
via macros assuming a local var for the api struct etc.

but either way for some java bindings this should do the work.

> A headless jvm works, 2d and widgets will, but 3D I haven't figured out.
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
> 


-- 
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>


More information about the Dev mailing list