I don't think SDL replace Evas_GL. SDL may give another option. If an application needs 2d widgets, it should use Evas_GL. We already provided performance optimization features for the usages (such as DirectRendering, FastPath). And we also provided utilities to make easy Evas_GL porting. Evas_GL is the best solution to mix 3d and 2d widget content in a canvas.
SDL is good for only 3d contents or engines which have its own widget such as unity. I totally agree that supporting SDL on Tizen is not easy, because I have experience DALi supports on Tizen. But the strategy should be different between DALi and SDL. DALi should work with all the other Tizen API's(NON-UI APIs). On the other hand, platform independency (portability) is the most important for SDL applications. At first, we should verify each SDL API can run on Tizen platform correctly. If SDL application need additional feature, we need to make SDL extensions/module and contribute to SDL community. We(Graphics/Window system/AppFW guys) are prototyping SDL integration on Tizen 3.0(wayland only). - appcore integration - add Tizen wayland video backend When I get confirm to support SDL, we can start more detail discussions for each technical item what you concerned. BRs, HyunJu --------- Original Message --------- Sender : Carsten Haitzler <carstenhaitzler> Date : 2016-05-26 10:57 (GMT+9) Title : Re: [Dev] SDL support on Tizen On Wed, 25 May 2016 10:49:18 +0000 신현주 <[email protected]> said: > Hi All, hey hyunju! fyi - sending this from my private account (subscribed to tizen mailing lists too as well as work) because the awesomeness of our IT system means we don't get mails from a @samsung.com address if it has gone to an external mailing list and come back in. something to fix. working on it. > I would like to propose using SDL 2.0 (Simple DirectMedia Layer) as Tizen > porting layer for game/game engines. > > Currently, Evas_GL is the only available interface to use OpenGL ES on Tizen. > > Though Evas_GL is simple and efficient interface for EFL widget based > applications to access openGL ES, > to attract more game/engine developer community towards Tizen, it should > support even more widely adopted cross-platform interface. just as a note - evas_gl allows you to mix 3d and 2d widget content in a canvas. SDL will not allow that. you'll be "take over the window entirely and do it all yourself". you can't make use of existing widgets in combination with your game. what do you do about indicator? what about client-side decorations in wayland? ... etc. efl will take care of it for you transparently and give you decorations in windowed modes without app needing to know. it merged 3d rendering into the scene graph "seamlessly". > I think SDL 2.0 is definitely a good candidate in this respect. > > > * Major Benefits include > > - Provides direct access to OpenGL ES API without any wrapper (fast) actually the evas gl "wrapper" does not much more than assign function ptrs to the original gl calls ... EXCEPT for some. it should have no real measurable impact on performance. the real issue probably is the gl context switch and this mostly depends on your driver and how well it switches contexts... :) > - Uses platform independent Window & Event handling API (portability) > > - Vulkan interface can be provided easily compare to Evas_Vulkan. (Evas > vulkan backend is not yet ready) actually we've only just talked about it. :) we need to do a lot more work to do this and it's not as high a priority as some other things, so it's "waiting". > * Possible Constraint is > > - Increases verification scope for tizen release actually so here are the things that need to be done just from the top of my head: * as you say - more libraries to test/verify * needs integration support with rotation API's/protocols for client-side rotation * needs to ensure integration support with input method framework (SCIM on X11 and wayland input method protocol and extensions) * needs support for any/all wayland extensions and/or x11 extensions we use to attach data to windows/surfaces for tizen. * need to check the state of the wayland support in SDL * you will have wonderful problems with appcore. i'll repeat this. appcore as an api should die as it just creates issues especially with toolkits and portability. this is along topic on its own. toolkitis should do the abstracting. if a feature is needed then it should be done by toolkit in the toolkit way - be that efl or SDL. this will mean having to extend SDL i suspect. * what about other native api's working. SDL doesn't require a mainloop at all. games basically are expected to run their own... now what? the right way would be to work on sdl modules/extensions to do this... * what about all the things that efl does "automatically" like forcing background windows to stop rendering when not visible (with global config options to control this), or throttle mainloop. we have messages sent to the apps to release resources when in the background - efl does this on its own, now SDL based apps need some mechanisms for this... one question - are we considering x11 at all or only wayland (tizen 3+)? i assume just wayland. the above was just a start. it's one thing to have SDL work on tizen (and i can tell you that it won't on tizen 2.x because we've managed to becomes non-standard that windows just don't display anymore and the screen effectively freezes if the app doesn't use appcore etc. etc. - this is bad). it's another thing to have it work WELL and integrate with tizen, provide SDL "style" abstractions and APIs for what is needed etc. if we want SDL to work we need to: 1. ensure tizen is far less of an "odd" fork of linux and have it work with standard apps and interfaces, BUT have the extra extensions to make things NICER for our use cases. this is independent of SDL. currently tizen is neither android nor ios nor "normal linux" it's some odd thing on its own. 1.1 to do this we have to start dogfooding. we have to use tizen day to day ourselves. you will never know all the non-standardness and breakage unless you experience it day to day. 2. look at a way of getting appcore features into both EFL and SDL in a "native way". this involves going through one at a time and either saying "drop or do in another way" or find a way to abstract it nicely. 3. work on extending SDL to support all the other extended things we do in tizen that are already handled transparently by EFL 4. work on all the other tizen API's and how they might work with an SDL using app. an initial "oh look - a window!" won't be too hard. it's all the extra stuff that will take time. the goal IMHO should be that an app that uses SDL can "simply just work" on tizen with recompilation (well and stuffing into the tizen directory hierarchy eg into its own application dir etc.). that should be the goal. we should try and get as close as possible. this would require a decent dedicated team to work on SDL, understand it, work with upstream etc. etc. remember SDL tries to be a very simple abstraction for games. it already abstracts: * graphics (3d/2d/windows) * input events * audio * file i/o * modules * timers * cpu info * power management and a few others. it's logical only that sdl probably wants to abstract the relevant things on tizen for apps to work without "porting". > Do you see any other benefit or Constraint? > > > Please share your opinions about this. > > > Best Regards, > HyunJu -- Carsten Haitzler (The Rasterman) <[email protected]>
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
