[Dev] SDL support on Tizen
hyunjushin at samsung.com
Fri May 27 12:20:18 GMT 2016
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.
--------- 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,
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
* as you say - more libraries to test/verify
* needs integration support with rotation API's/protocols for client-side
* 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
* 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
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
* file i/o
* 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,
Carsten Haitzler (The Rasterman) <tizen at rasterman.com>
More information about the Dev