[Dev] SDL support on Tizen

Carsten Haitzler (The Rasterman) tizen at rasterman.com
Sat May 28 00:44:15 GMT 2016

On Fri, 27 May 2016 12:20:18 +0000 신현주 <hyunjushin at samsung.com> said:

> I don't think SDL replace Evas_GL. SDL may give another option. If an

not saying it does .. or doesn't, but if SDL is to be truly useful (on tizen)
it'll have to solve a bunch of things and provide abstractions. :)

> 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.     

indeed that was my point. you almost definitely WILL have to.

> We(Graphics/Window system/AppFW guys) are prototyping SDL integration on
> Tizen 3.0(wayland only). 
> - appcore integration
> - add Tizen wayland video backend

how are you integrating to appcore. the moment you REQUIRE appcore to be used
by apps, you just broke portability. if an app can be written "as normal" just
using SDL + libc etc. API's then it's truly portable. :)

> When I get confirm to support SDL, we can start more detail discussions for
> each technical item what you concerned.

well discussion the possible amount of work invovled is part of it. :)

> 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 신현주 <hyunjushin at samsung.com> 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) <tizen at rasterman.com>

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

More information about the Dev mailing list