[Dev]   SDL support on Tizen

Peter jini at zeus.net.au
Sun May 29 04:08:57 GMT 2016


Thanks Carsten,

Where's the best place to start looking to learn about Eolian?  I've 
done an initial web search which turned up some presentations.

Is Eolian specific to Enlightenment, or are there plans for Samsung to 
use it for other Tizen api's as well?

The JOGL library uses Gluegen to generate it's java bindings.  JOGL has 
a number of different back ends, I haven't quite got my head around how 
to create a back end based on enlightenment yet, it did seem like a 
difficult task.  I looked at some of the gl application examples for 
Tizen developers in Samsung's sample programs, but decided to focus on 
creating java bindings for the Tizen api's first.

I'm glad Enlightenment isn't written in C++.

Regards,

Peter.

On 28/05/2016 11:01 AM, Carsten Haitzler (The Rasterman) wrote:
> 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
>>



More information about the Dev mailing list