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
