------- Original Message ------- Sender : huanhuan zhu<huanhuan....@samsung.com> Senior Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics Date : Jul 11, 2016 18:52 (GMT+08:00) Title : Re: ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman)) (Carsten Haitzler)
Hi Carsten Haitzler About SDL it does not need to consider too complicated case: 1. It can draw in one window, for multi window case, if top window update can cause background window dirty and force update. 2. It can force update screen by eglSwapBuffer which is not allowed in efl. So assumption only one orientation is needed in SDL application, and use this structure can solve the problem of ecore_mainloop is not compatible with SDL app. BR Zhu huanhuan Sorry I list my previous page below and for discuss ============== Sender : huanhuan zhu 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 : huanhuan zhu<huanhuan....@samsung.com> Senior Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics Date : Jul 11, 2016 18:49 (GMT+08:00) Title : Re: Dev Digest, Vol 35, Issue 6 Hi Carsten Haitzler About SDL it does not need to consider too complicated case: 1. It can draw in one window, for multi window case, if top window update can cause background window dirty and force update. 2. It can force update screen by eglSwapBuffer which is not allowed in efl. So assumption only one orientation is needed in SDL application, and use this structure can solve the problem of ecore_mainloop is not compatible with SDL app. BR Zhu huanhuan ------- Original Message ------- Sender : dev-requ...@lists.tizen.org<dev-requ...@lists.tizen.org> Date : Jul 08, 2016 20:00 (GMT+08:00) Title : Dev Digest, Vol 35, Issue 6 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)) (Carsten Haitzler) ---------------------------------------------------------------------- Message: 1 Date: Fri, 08 Jul 2016 10:59:01 +0900 From: Carsten Haitzler To: sidein Cc: dev@lists.tizen.org Subject: Re: [Dev] ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman)) Message-ID: <20160708105901.12675e47@fatty> Content-Type: text/plain; charset=US-ASCII On Fri, 08 Jul 2016 10:52:50 +0900 sidein wrote: > Hi Raster, > > The rotation's event is sent by Application framework. well first this is poor design. rotation is not an application global thing. its per screen. imagine your desktop with rotatable monitors and you have 2 of them? tizen by design here is broken. you can never do that using appframework. anyway what i did mean is the rotation negotiation with the compositor. e.g. say "i'm ready to rotate". "i can handle these rotation angles" and "i'm done drawing the newly rotated buffer" etc. > SDL Application just know current orientation. > So, it does not have the client-side rotation. > I know that SDL GL application render and composite to surface by > himself. I think that client-side rotation is not needed in SDL. > I wonder why you think that. Would you explain? ^^^ as above. at least efl does this rotation transparently for apps hand then handles translating input coordinates etc. so app simply handles a resize like any window can resize. it would be simpler for sdl apps this way. > About indicator, I'm implementing the prototype in tizen backend. > Maybe he uses ecore_ipc and the other tizen services. > I concern this control is only for Tizen. yes and no. for wayland, decorations (border, title etc.) are meant to be done client-side. this is something sdl has to handle conceptually anyway if it wants a windowed mode in wayland. doing indicator is simply using the indicator as a titlebar basically. :) > If most of SDL GL applications work fine in Tizen Device, I will > upstream. :) > > Thank you, > Wonsik > > -----Original Message----- > From: Carsten Haitzler [mailto:c.haitz...@samsung.com] > Sent: Friday, July 08, 2016 10:28 AM > To: sidein > Cc: dev@lists.tizen.org > Subject: Re: [Dev] ??SDL?support?on?Tizen (Carsten Haitzler (The > Rasterman)) > > On Fri, 08 Jul 2016 10:24:20 +0900 > sidein 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=t > > ree;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 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 > > > > > > > > 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?obj > > ect?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?s > > pecial > > > > > 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?st > > atical > > 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?ge > > neral > > > 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?s > > ame?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?pos > > sible > > > 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,?a > > nd?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?file > > s?(we > > > > > targetted?luajit?making?use?of?ffi?to?bind),?and?if?you?--enable?it,?t > > he?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,?b > > ut?the > > re > > > > > is?a?libeolian?that?does?all?the?.eo?file?parsing?and?manages?an?in-me > > mory?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?j > > > ust?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?imp > > >ressed > > ?by > > > > > >?>>?the?object?orientated?nature?of?Enlightenment?and?how?easy?it?is? > > >to?han > > d > > > > > >?>>?craft?java?bindings?for,?following?the?inheritance?hierarchy.??To > > >ols?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?th > > >ats?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?bindin > > >gs.?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?hig > > >h?leve > > l > > > > > >?>?abstraction?and?eolian?generates/maintains?the?c?boilerplate?and?t > > >here?a > > re > > > >?>?various?binding?generators?per?one?of?the?above?languages.?writi > > > >ng?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?to > > >p?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?gener > > >ator?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?method > > >s.?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?JoG > > >L?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?wayl > > >and?fo > > r > > > > > >?>?example?(as?i've?been?doing?this?stuff?for?a?long?time...?to?do?th > > >is?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?loo > > >k?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.?-?t > > >here?i > > s > > > > > >?>?even?a?helper?header?that?removed?the?need?for?glapi->func()?and?a > > >llows > > > >?>?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?figur > > >ed?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 > > ------------------------------ Subject: Digest Footer _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev ------------------------------ End of Dev Digest, Vol 35, Issue 6 ********************************** _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
