On Fri, 08 Jul 2016 10:24:20 +0900 sidein <sid...@samsung.com> wrote:
> Hi All, > > > > I 'm preparing to support SDL on Tizen. > > For that, we make tizen backend in SDL 2. > > It is similar to the other platforms as windows, iOS. > > Current status is the below. > > 1. Work with tizen Application framework > > 2. Support Tizen ISF, dlog and rotation > > > > To support Tizen specific functions, Tizen backend uses some Tizen > APIs as a eocre_wl. is this for things like client-side rotation, rotation protocols, indicator stuff etc.? > If you want to see current source code, check the below that, plz. > > https://review.tizen.org/gerrit/gitweb?p=platform/upstream/SDL.git;a=tree;h= > refs/heads/tizen;hb=refs/heads/tizen oh cool. btw. thanks for the mail shout out. i wish more people would do this. > Thank you > > Wonsik > > ------- Original Message ------- > > Sender : huanhuan zhu<huanhuan....@samsung.com> Senior > Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics > > Date : Jun 03, 2016 11:41 (GMT+08:00) > > Title : Re: Dev Digest, Vol 33, Issue 19 > > > > Hi All > > This is Zhu huanhuan who worked NDK project in TV before. > > Let me give my personal opinion, > > A. Why we need NDK ? > > It is not used for application development directly, it is used for > game engine porting their module over Tizen. > > So we do not need to care about UI/FW or language, 3rd developers do > not care. > > > > B. Why NDK need SDL ? > > 1. Not exactly, we can also refer Android to supply Surface and EGL > init & OpenGLES call directly ( I think it is also good) > > > > C. Analysis SDL. > > 1. SDL similar as windows application, application side hold main-loop > itself. > > SDL does not care how to integrate platform's appframework who is > incharge of lifecycle management. > > For example all application in windows need a X button and close > itself. TaskManager just do kill one process works. > > main() is the entrance of application directly. > > 2. Android / Tizen which has internal glib's g_main_loop to handle the > main-loop. > > The AppManager want to handle to launch and terminate works by OS > directly and front-ground/back-ground case. > > So application need register render callback based main-loop and app > manager is handled in OnXXX callback. > > > > For android case, it use one thread to handle lifecycle and render. > > For EFL case, it is same but it has a problem of integrate EGL > inside.(which is a issue I will talk latter) > > For Dali case, it divides two thread for lifecycle and render , which > I think is a waster of performance. > > > > So SDL has issue now in Tizen. > > 1. How to integrate to AppFW if main-loop conflict exist. > > Let's see how android do for SDL, it create similar structure as > dali, event thread(main thread) for applifecycle and inputs, render > thread for SDL to handle SDL main-loop. So two thread is needed > ( Somehow a waste) One is for Ecore, another is for SDL main > > > > > > Is there other solution ? > > Yes, we can refer Android NDK case directly, but issue exist that > evasGL is conflict pure EGL > > that we can not use EFL window, so it will be look like that: > > Ecore+ EcoreX/EcoreWayland window create > > Get surface and pass to user, > > User do EGL init and call OpenGLES api directly > > Handle inputs from XInput or Wayland inputs. > > > > BR > > Zhu huanhuan > > > > > > > > ------- Original Message ------- > > Sender : dev-requ...@lists.tizen.org > <mailto:dev-requ...@lists.tizen.org%3cdev-requ...@lists.tizen.org> > <dev-requ...@lists.tizen.org> > > Date : May 30, 2016 20:00 (GMT+08:00) > > Title : Dev Digest, Vol 33, Issue 19 > > > > Send Dev mailing list submissions to > dev@lists.tizen.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.tizen.org/listinfo/dev > or, via email, send a message with subject or body 'help' to > dev-requ...@lists.tizen.org > > You can reach the person managing the list at > dev-ow...@lists.tizen.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dev digest..." > > > Today's Topics: > > 1. Re: ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman)) > 2. Re: ??SDL?support?on?Tizen (Peter) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 May 2016 16:26:37 +0900 > From: Carsten Haitzler (The Rasterman) > To: Peter > Cc: "dev@lists.tizen.org" > Subject: Re: [Dev] ??SDL?support?on?Tizen > Message-ID: <20160530162637.1b33c172124636a55bf9e...@rasterman.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, 30 May 2016 16:41:41 +1000 (AEST) Peter 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 > > Sent: 30/05/2016 10:58:08 am > > To: Peter > > Cc: dev@lists.tizen.org > > Subject: Re: [Dev] ??SDL?support?on?Tizen > > > > On?Sun,?29?May?2016?14:08:57?+1000?Peter??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?mo > del > > 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?t > he > > 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?statical > ly > > 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?the > n > > > 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?the > re > > > is?a?libeolian?that?does?all?the?.eo?file?parsing?and?manages?an?in-memory?d > b > > 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??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?han > d > > > >?>>?craft?java?bindings?for,?following?the?inheritance?hierarchy.??Tools?th > at > > >?>>?generate?bindings?don't?do?so?well. > > > >?>?orly??everyone?keeps?going?"efl?is?not?oo!?make?it?oo!?(rewrite?in?c++?i > s > > > >?>?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?wh > at > > > >?>?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?leve > l > > > >?>?abstraction?and?eolian?generates/maintains?the?c?boilerplate?and?there?a > re > > >?>?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?t > his > > > >?>?handling?reference?counting?and?more.?considering?the?constraints?of?thi > ngs > > > >?>?like?js?and?lua?i?think?java?should?be?easy.?once?you?have?a?generator?t > hen > > > >?>?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?nativ > e > > >?>>?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?fo > r > > > >?>?example?(as?i've?been?doing?this?stuff?for?a?long?time...?to?do?this?RIG > HT > > > >?>?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?t > he > > > >?>?glview?examples?in?elementary_test??if?you?enable?direct?rendering?fyi?. > .. > > > >?>?you?get?zero?overhead?support?-?no?extra?copies.?the?api?funcs?are?almos > t > > > >?>?all?just?direct?pass?down?except?a?few?like?scissor?stuff?etc.?-?there?i > s > > > >?>?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)? > > > > > > _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
