[Dev]   SDL support on Tizen

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Mon May 30 07:26:37 GMT 2016


On Mon, 30 May 2016 16:41:41 +1000 (AEST) Peter <jini at zeus.net.au> said:

>  
> Thanks Carsten,
> 
> Yes java jni code generation.  Thanks for the references this helps a lot.

:) On the same page then.

> It's a shame Eolian use doesn't extend to Tizen api's, perhaps Samsung may
> reconsider? 

I have suggested it many times. Evenm if all it was was a simple eo wrapper
on top of existing native API's, then we'd get "binding auto generation" for
free. The more languages eolian supports, tyhen the more languages come "fore
free". (someone has to run the generator to generate bindings - EFL runs it
just as part of "make", tizen native API's could do whatever they wanted as
long as it is run).

> Samsung: Automation trumps manual editing every time, the parser and

Absolutely. That is the premise behind doing auto-generation. We have done
manual bindings many times for EFL. The Python bindings are still manually
maintained and they are always behind the C API and lacking features. It's
manual effort. It's boring work. It's painful. It's error-prone.
Auto-generation takes longer to get right (we've been working on this for a
while to get it right and to get it to fit multiple targets), but in the long
run it saves much more time. Slow to start, fast to finish. The big plus is
indeed "no maintenance". If the generator has a bug, it gets fixed there once
for all languages and API's, so at worst the maintenance is this.

> generators will end up being thoroughly tested in the long run, significantly
> reducing bugs and saving many wasted development hours that could be spent on
> more important work.  

Yup. Bingo.

> Having the worlds most popular programming language running on Tizen makes a
> lot of sense too (It's the language of Android).  Tiobe index:
> 
> Java 21%
> C 13.2%
> C++ 6.7%
> JavaScript 2.3%
> Swift 1.6%
> Objective-C 1.6%

I would happen to agree. Though you missed Python, C#, PHP. :) I think PHP is
inappropriate for Tizen EXCEPT perhaps for making remote UI's that serve HTML5.
Swift I just am not sure about and is too new. C, C++ and Java have been
long-standing top-languages for the last 2 decades for just about as long as
I've seen popularity comparison charts. Even if C were not popular, it's the
lowest level "lingua franca" that just about every runtime, vm, language etc.
relies on (be it just to build on or as the basic ABI), so it's a good base.

Then offer API's in higher level languages so you can include as many
programmers as possible. Personally me and Java have had... not so great
interactions, but I'll definitely say that it's one of the long-standing
popular languages out there.

Objective-C seems to be rapidly on the way out thanks to swift and other forces.

C# I'm just neutral on. I hear good things, but otherwise have no opinion other
than it having been traditionally not accepted among open source circles for
various reasons (some of them good).

JS I'm neutral on too - but of my preferred languages for "dynamic quick and
dirty development" It'd be in my top 2. Lua would be right up there just due to
size and speed.

Python is just incredibly popular especially among learners who are still
getting started.

> Java and C are the only languages with market share in double digits, these
> two together have more than one third of total developer market share. 
> 
> The increase in Java last year alone (+4%) was almost twice the total for
> JavaScript.  
> 
> Increasing available apps is more likely to occur if you double the number of
> developers who can write programs for your platform.

I would agree, though we need to do much more than that. We need to have a
"WOW" factor for Tizen, and frankly... we have never had it. Something that
makes people (developers, users, someone) go "WOW ... that's amazing. I WANT
THAT". I can go on all day about things that would have the WOW factor...
things i know by studying of market (developers at least) would make them go
WOW and turn up, but this is not the time or thread for that. :)

> It would make it a lot easier for developers to create native ports of
> Android apps, provided the presentation and application layers are cleanly
> separated.

Agreed.

> Most recent UI's can be defined using xml, including Android, JavaFX and
> Apache Pivot, among many others, which does make me wonder if generators can
> be written to transform these into enlightenment ui components for simple
> applications, the parsers already exist and are open?  Far superior to
> android emulation.

Possibly.

> The jvm and libs can be stripped down using compact profiles and jvms can
> share class files to reduce start up time  The jvm is 2x faster than Android,
> although I believe startup can be slower for Java.

TBH I think we need to stand back and re-think how we deal with the OS + apps.

As time goes on, more and more apps bundle libraries, runtimes etc. into the
apps. this just duplicates and creates a mess. Apps bloat out horribly in size.

I think we should split things into 3 groups

1. Core OS.
2. Runtimes/middleware
3. Apps

Runtimes would include the Tizen Web App Runtime. They would include Java if
there. Each runtime would be versioned with a new install per version. Apps
simply indicate which runtime and which version they want. Runtimes would be
installed as package dependencies automatically (and uninstalled when zero apps
reference them after removal).

This would allow runtimes to be updated rapidly where the core os can only be
slowly updated. It would allow new communities to turn up and support specific
runtimes themselves. Enough people want Python - sure. add it to the runtime
"store" and support it. This would by design de-duplicate all the installs
inside every app. It'd keep memory footprint low as mmap()ing the same file for
the same code, since it's shared, uses only one piece of memory rather than 2 or
3 or 4 apps shipping copies of the same code buried in their shipped-with-app
runtimes using many peices multiplying the footprint and I/O needed to load
the data into RAM. It'd keep Tizen efficient AND flexible.

The only thing to really argue is how much should be in the runtimes. Can it
include shared libraries? how will these override system ones (launcher can
just set LD_LIBRARY_PATH for an app...). And security. Now apps depend on these
middleware code blobs... how to ensure they are not compromised. Personally I'd
take the view that any runtime or middleware MSUT be shipped as source. No
binaries. It has to be auditable and compiled/packages by trusted servers, not
the submitters. But that's a long discussion.

> JOGL supports both Jvm and Android platforms for 3D cross platform
> compatibility.
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
> ---- Original message ----
> From: Carsten Haitzler <tizen at rasterman.com>
> Sent: 30/05/2016 10:58:08 am
> To: Peter <jini at zeus.net.au>
> Cc: dev at lists.tizen.org <dev at lists.tizen.org>
> Subject: Re: [Dev]   SDL support on Tizen
> 
> On Sun, 29 May 2016 14:08:57 +1000 Peter <jini at zeus.net.au> said: 
> 
> > 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? 
> 
> eolian is specific to efl indeed. we wrote it specifically for the object model 
> we created and for the purpose of making bindings directly from source. 
> consider this like gobject but with a very different take on how to do a 
> generic object model in c. eo (the object model) and elian were built from the 
> get-go to: 
> 
> 1. be able to back our existing code and so it requires specific and special 
> solutions 
> 2. to be able to act as a "language neutral" IDL system to define APIs that 
> appear in C but also then map directly to other languages - be they statically 
> typed or dynamically typed, explicitly memory managed or GC'd like C+
> +, JS, Lua so far. 
> 3. save us work in C by writing and maintaining boilerplate C code for us. 
> 
> this is old and eo syntax has changed since but it gives a bit of a general 
> intro: 
> 
> https://phab.enlightenment.org/phame/post/view/75/yet_another_c_object_model_-_but_better/ 
> 
> we don't have the eo_do() construct anymore, but eo_add() can do the same by 
> calling methods to setup up an object at construction time, so objects have 
> finalizers to call after these setup methods are called. it's meant to be a way 
> to optimize objects by deferring as much work f object creation as possible 
> until the finalize when we know the initial state. 
> 
> if you find all the *.eo files in efl you'll see how it works soon enough: 
> 
>   git clone https://git.enlightenment.org/core/efl.git 
>   cd efl 
>   find . -name '*.eo' -print 
> 
> those eo files. from those eo files C core/boilerplate is generated, and then 
> the actual implementation code is filled in. from those eo files also the c++ 
> *.hh files that are the bindings are generated as well as the lua files (we 
> targetted luajit making use of ffi to bind), and if you --enable it, the js 
> bindings (c++ v8/node.js code). 
> 
> for java i assume you'd want to generate possibly java code that uses jni to 
> call the original c. someone has to write the eolian_java generator, but there 
> is a libeolian that does all the .eo file parsing and manages an in-memory db 
> of everything to make it easy. 
> 
> no - the rest of tizen doesn't use this. to date there has been no interest. 
> they seem to prefer to do things by hand. 
> 
> > 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. 
> 
> hmm ok - so it's generated. the evas_gl stuff is plain c functions just as 
> function pointers in a struct. the eo/eolian stuff doesn't cover it. doe to its 
> nature it'd have to be manually bound. 
> 
> > I'm glad Enlightenment isn't written in C++. 
> 
> at least there are a few of you. :) 
> 
> > 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 
> > >> 
>> 
> 
> --  
> Carsten Haitzler (The Rasterman) <tizen at rasterman.com> 
> 
> 


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


More information about the Dev mailing list