 I'm going to be talking today about our Enlightenment Foundation Library 2.0 and more like what we're trying to go to get there and that's a lot of ideas that are going on there and it's still like early time so you can still join and participate in the discussion. So I am Cedric Bay, I'm working for Samsung open source group in Mountain View and I've been working on EFL for more than a decade now, I think. Time pass. And so for people who don't know what EFL is I will just go quickly over what it is. It's a toolkit created for Enlightenment 17. Enlightenment 17 has been like a long coming project. It was in 1997 and it only was released in 2011, if I remember correctly. And the reason it took so much time to do a window manager is because we didn't just fully rewrite it but we also write a toolkit to make it possible. And we designed this toolkit for mostly all need and what we were thinking of what was going to be the future when we started and it was embedded device. And we were designing Enlightenment and EFL to be able to scale and to be running on embedded device. A few years later Samsung did pick it up and it does fit Samsung in an embedded device. So every device that is not Android phone pretty much is usually is now running with Enlightenment and EFL. That means TV, camera, fridge, digital appliance, pretty much anything that has a screen will be running with Enlightenment and EFL. As it is now used in product we have very strong goal and we are able to try to not break API and ABI because that means that we will be breaking application. That is really core to EFL and we are in the process of making the released 1.21 of EFL. The first number means that we have not we have tried to not break API since 1.0 and so that's a 21 version on 1.0. Misapp does happen. Sometimes we are at a point where some people are relying on bugs to make the application working. It has been 10 years since more than 10 years so there is this kind of things and so you end up with a situation where you actually fix a bug or you break application. It's kind of an interesting challenge coming there. So even if EFL was designed for a window manager it's now used for any type of application. It is doing its own rendering. It has its own scene graph and this scene graph has been developed over more than a decade so it's one of the most optimized one you can find. It's targeting to reduce CPU, GPU, memory usage and that does lead to actually saving battery. The optimization, you are pushing 60 frames per second you are not going to be seeing more than that because the battery usage is going to be something you will notice. So once you are fast that's good but the next step is also to be efficient on the energy usage of your stack which is one of the things that we have been spending the past few years working on EFL. Obviously you need international support that means being able to support left to right, right to left, UTF-8, translation and all of these things so that's part of the toolkit. You need to be able to scale that means scale from number of CPU from screen, from GPU, without GPU with input device of all kind of form and shape with different precision and latency and so we do have a lot of code to handle all these variations in the toolkit itself. We also support accessibility and being on, targeting on the device the ability to completely customize the look of your toolkit has been really important so we do have our fully themeable layer engine for EFL and that's kind of core of EFL too. And to mix all these parameters because it's a lot of configuration we have a notion of profile and you can attach a profile per screen so when you move your application from one screen to another it will reconfigure itself to fit for that screen and the input method that are linked to that screen. But all of that doesn't come with a huge cost we can make EFL fit into 8 megabytes with a minimal set of dependencies it's very modular, we can remove things it does really scale down quite a lot which is pretty neat but 15 years of organic grow with our no refactoring of the API because that's breaking application it has been also very strong focus on performance and new feature and not much on API so we have been a multiplication like multiplication of API our different behavior on which part of the library you are using because they are not the same object model and stuff like that so we have been starting for now more than two years to be working on EFL 2 and basically the goal the main goal that we have is to make it easier for people and one of the main way to make things easier for people is actually to provide them a full support for the language they prefer because everyone has their favorite language there are I think enough in this room that everyone has a different language they like and so of course we have thousands of API for our toolkit the size of EFL and it will not be something that will scale if we have to write bindings manually so obviously we need a way to generate bindings efficiently for every language we can in a maintainable way we want also to have documentation that does match each language so that we have also the documentation that does fit your use of the toolkit so that you don't rely on the C documentation to be able to actually use it in Python that is something that would be kind of harder on people so that is kind of really the core of the work and we want also to make sure that when we do a release the day of the release every bindings has actually full support for all of their new API we are pushing so from there it also pushes us to have a simpler API so we want to have the same function across all part of the libraries because EFL is a mix of libraries and so we want to make sure that we have the same object model the same event system the same asynchronous system we want to have refactor all of that and we want to do that by also being I mean we are in 2018 now we want to be a little bit more modern and do proper life cycle support and make sure that the life cycle support that we have does match every binding so that they have like in C++ you will have AII so on the reference no pointer we want to make sure that all of these things are available to you and oops sorry and so one of the big thing is we realize it's a lot of work and we cannot really release EFL 2.0 right away and say now there is no application working anymore and you have to just work and port your application all the toolkit I've been trying to do that and they have used community and they were able to move and it took them almost a decade so that is not something as enlightened community we can actually do because we don't have the scale so we want to maintain and that's very important to us API and ABI compatibility and for as long as possible so basically you will be able to use the legacy API alongside EFL API, new API in the same binary so you can actually start migrating part of your code to the new our new system without breaking the old system and that's really core this is mostly for C application it might be also possible with Python because today we have really one binding that is maintained and that's a Python binding and so it will be neat if we can manage that also with Python but for sure we are doing it with C and at the C level at least your application will not be broken and you will be able to slowly migrate to the new API also we want to preserve all the benefit of EFL and that means also we want to preserve that at the binding level so if we were to do C++ we want to make sure that the indirection that you go through in C++ is not going to cost you anything and that you should be at the same performance level if you were in C and so I will be talking maybe later a bit more about C++ bindings because that was the first binding that was actually being think through this system but we want to preserve the energy efficiency we want to preserve memory usage and we want to spread out all scalability basically everything that makes EFL today we want to preserve that and we just want to change the entry point and make sure that when you write an application with EFL you will be able to really use all these features and performance that are there without making an application that will be blocking or anything so one of the core things that we are doing is a new object model for EFL we are naming it EO but that's really just a library name it's not really that important it's basically cleaning up all our object model into one that does ref counting with parent relationship also it's very simple classic life cycle we have constructor, finalize we have our constructor really classic things there each object can carry events and all of that is on your object model but that was not enough for us to actually be addressing our bindings so for bindings need we came up we didn't want to reinvent a new language to do all the documentation of our binding generator or we didn't want to switch to a new language we wanted to continue to be C and then enable binding on top so we worked on a language that's named Aeolian and that one does look like that and it's basically kind of Jason looking like kind of not but the idea that are in that language you can describe all your object property all your function you can provide parameters that will say each function is going to be doing what and you also provide documentation so I have removed a lot of the documentation that is actually in the real your file because it will not fit in the screen but the idea is that the binding generator can actually read the documentation and transform that into the documentation that you expect in that language and there is already the C-sharp binding during that because in C-sharp people expect documentation to be in XML and so there is some automatic redo of the documentation and that is generating proper C-sharp documentation we also put into the, I was just saying before that in EO we have objects with events on it and so events and all of the really all the behavior of the object is documented in the EO file and that generates not just the binding but also all the C boilerplate so when you are writing a C you, a C class, you will actually get a .h generated from the EO file and a .c and when you include that into your C file your function will be properly type-checked and everything it will be just you have a static function to implement all of the placeholders there you will notice that the Ilgen file is only about the public API there is nothing about private function there is nothing about like private data nothing like that that is exposed and you can have all private functions and private data you want outside of the EO file in the case of EFL 2.0 basically we are working on tools that are going to do automatic audits of our entire EO file to make sure that we are coherent and that nothing is missing that there is no like redundant things and that is looking quite well for now we have automatic warning when we are adding new function we are doing something that is looking like something is already there to just notify us early on that some feature might be better expressed some other way one other thing that we are doing is that EFL was a bunch of library with very weird names it was evas, ecore, edge elementary which doesn't ring a bell to anyone but what they could be doing so when you were a beginner that was really a steep starting point because you really didn't know where to start from so with the new API we are looking to start with three types of application and you will have core net and UI which already talk by themselves about what each of them do and that will be your entry point into the library you will be linking to EFL core EFL UI or EFL net and you will be including EFL core on net or UI and that's it and you should not see any more namespace that are kind of fun but if you want to be more mainstream it's required to be a little bit less creative on the naming I think and we are also still trying to do a lot of the automatic instantiation and insertization of EFL for you and we still support some old technique to do a fast starting of your application it's something we really use in Tizen we basically pre-start EFL in a process pool and when you start an application it is right away EFL is already established and you can just take one of its pending process and say launch that binary from there and it does a little bit of magic with deal open and manage to start the main loop from there so we are keeping all of that and building your application will be around the main loop and the main loop provides you also with application lifecycle and this is really important on a bit of device because you have the possibility to have your application being posed, resumed or terminate and the idea is when you have pressure on the system or some component on the system will tell you now you should actually pose and the idea is that all your graphic resource will be dumped and if you have an application and you want to be more you can for example start to slow down the amount of time you get data from the network or drop some stuff from your memory and things like that so all of this lifecycle is now part of EFL and it is actually something that is automatically also working on the desktop and so on the desktop what we do is that when you minimize your application it does pose and when you maximize it does resume and that is something that is working per window and at the level of the application too so you can have the view on each window or at the application level the main loop is caught to basically all the event driving in your application so it does provide our information of when the main loop is idle and doing nothing it enables you to asynchronously schedule jobs and as I was talking just before we are having this problem of bug compatibility and so to address the bug compatibility we are pushing basically you are not just saying which EFL version did build with but which EFL version did develop with on the main loop and that will configure the entire system to be as much bug compatible as we can with that version of EFL it's not like the silver bullet solution because if you are using library that are using EFL itself it will mean that everyone has to be synchronized on that version of EFL but it does already help for a lot of scenario for us one of the evolution we have which is kind of silly to say but when we did build EFL we did build EFL in independent component or the idea when we started 2001 was we didn't want to make evas the scene graph and our rendering library be our EFL only component because we were thinking it's a lot of work to do yourself and every toolkit should be actually be using that and so that component and a lot of the logic of EFL at the time was every component is individual and can be reused in another toolkit we were expecting that maybe all the toolkit will be picking it up and doing their rendering with the scene graph well most toolkit didn't use the scene graph for another decade and so it was a waste of time on all side to do this way and it actually started to make things more complex than it should have been and one of the place where it has been is animation basically if you want to do an animation you need to have a main loop but if you want to have a main loop then you are looking to lock your canvas with a specific main loop and so then you are linking yourself with a specific toolkit with EFL 2.0 basically we are saying well there is no point every toolkit wants to work in their own way and we should do more to work and so the canvas now is using the main loop it actually depends on the main loop to be there and if you want to drive an animation you can actually drive the animation off an object from the canvas and you have the animation synchronization there it goes even further than that especially on Welland the animation tick is per window so it's a good thing that is actually linked with the canvas it actually allows us for optimization where we can actually make sure that we are ticking at the frame rate off the screen per window but even if we are for example the window is only visible in a small tray this one doesn't need to be refreshed at 60 frames per second so we can actually get Welland to only request 30-15 frames per second for the window the new API you are actually very easily able to get that animation tick to be completely calibrated to the system and that leads to a lot of optimization because obviously your animation is what consumes the most of your energy when you are doing graphics so being able to dynamically adapt on the use case is also useful so it's not just about making things simpler but in some cases it's a real improvement on the technical performance side of things one other problem we have with current API is that it's actually hard for people to do asynchronous work because we only have events and you have race condition and you have to get all of these things in the right order right way so we are trying to find a proper way to express a series of commands into an asynchronous way it's still a lot of discussion there but the promise future that is radically what C++ is having JavaScript is kind of the same thing pretty much every language today as this kind of feature is something that we are starting to roll into multiple place in EFL and that does allow you to chain command step by step and not forget to unwrap an object but do that after you have actually used the property to actually put the object at some place and so on so that's where we are on the asynchronous thing and we really look for like chaining action because that's one of the things that is the most confusing when you are doing asynchronous things is that you have to synchronize things together and you have to do them in the right order asynchronously so it's a it's not a trivial thing for a lot of people so we are hoping that this kind of pattern are going to be enabling people to do things more easily one of the big problem we had in EFL was the network part it has been a very weird API for a long time and so a full redo of the API has been done and it now completely abstracts the protocol so if you are using UDP, TCP, HTTP or even like SSH and HTTP in the same like stacking 5 at the end you are still able to send data in the same way and you can actually chain all this protocol one after of each other quite easily and that's like really enable a much easier time with network especially when pretty much everything has to be networked so that's a big change too as I was saying we are moving to have more meaningful name for most of our namespace before we had EVAS which was called CANVAS but it was also CANVAS for Victor graphics it was also for 3D objects and everything was kind of there into weird namespace so today we are introducing a new name space we have CANVAS which are for 2D graphics primitive we have the CANVAS VG which is for Victor graphics primitive we have CANVAS 3D which is for 3D primitive it's not like we want to do games it's just if we want to display a small 3D icon or things like that being able to push that into the CANVAS makes sense especially if you were to enable one day 3D stereoscopic view or things like that you kind of need information at the CANVAS level to be able to do that automatically so that's why it's there and then EFL UI is where all the higher level widgets are so that's where you will find your button, your list, your checkbox all of these high level widgets and when we were doing this CANVAS with namespace we realized that we have a lot of function that are spread around all of our namespace for example file set we have file set on EVAS we have file set on every single object pretty much of elementary and it's like it should be just EFL file set for every object that is actually providing a file set feature so a lot of the refactoring has been to go around figure out all of the functions that have the same idea behind them and refactor that so there is a lot of this interface that have been going all the way back to EFL namespace and have this kind of abstraction for you so the current state for us is the CANVAS part is pretty much done EFL CANVAS namespace is done our EFL core is there is some part that we are not really settled down on especially regarding threading that is an API that is not looking like we really want there is network is pretty much done I don't think there will be much change on that but the EFL UI part where we have all the widgets is where we have a lot of work and we kind of did a mistake there because we were thinking we can actually just wrap the old widgets with a new API and we will have things fine but that's where we realized that some of the API have weird behavior that are borderline being bugs and so when you start to want to fix this behavior that we are kind of bad then you realize that you are breaking legacy API and your new widgets and so you have conflict there and it makes life a lot more like harder than you think it was and it was actually way easier to do clean from scratch widgets than it was to actually rely on the old widgets and we did spend a lot of time trying to reuse the old thing for the new one and that was not really a good decision when we now are a year later after that it's easy to say that now but when we were into it it was making sense to reuse code but now it's kind of too much conflict so from there we are trying to first focus on making the minimum set of widgets that we need for Samsung that mean providing touchscreen, mobile and TV set so typically there is toolbar and menu that are not useful for example on any of this device but they are really useful on desktop so for the first release we are unlikely to have that widgets there but it's not really a big problem I think because as we say we have legacy API still working so you should be able to mix the legacy toolbar widgets with the new widgets and you should be able to do your application on the long term we will be obviously working on providing the missing widgets because we want a full support there there is no point into not supporting the desktop use case so as you understand there is still a lot of work and so there is a long ongoing discussion about how we do thread and that is like really going on mainly the discussion is how do we provide people have been requesting thread safety but in C you cannot do thread safety except if you have one big lock and every time you access a function everything lock but that's not really useful because then you have not really multiple thread running at the same time the other way around is to have the object that only live in one thread but then you cannot easily access a thread object from another thread and so you are in a limited place the last step is to try to find a way to do smaller locking into the object system so that you actually are able to get your object living in all thread but you then don't have thread safety because in that case it's depending on the user to properly synchronize all of its thread to not do access on an object that is dying or an object that is in the wrong state so C basically make it impossible to have a fast thread safety model and that's kind of the discussion there because we are there is two direction either we provide something fast but then there is risk that the user do something bad but that's mostly something that will impact the C user and not anyone on another language pretty much well maybe not C++ but like if you do Python it's really unlikely that you are able to do this kind of bad things so that's a really ongoing discussion there if you want to join the fun the other part of the infrastructure that we are still working on and that is also really going to be an important new feature is to have a model view model infrastructure so most people are no MVC but MVC kind of lacks some of the design that MVVM do provide especially with MVVM you can really easily get the view out and replace it with a view test and make sure that your model does behave the view model does behave actually in the way you want and you can actually almost test everything that will drive your UI from the test without having to make the view run that's one of the really nice part of it and if you can switch your view so easily it means that you have the reusability of your component that is pretty high so it's pretty simple as a principle you basically are just connecting property on the view to the view model and the view model is proxy to models and so view model just do some of the math or basically say oh I need to know if this task if this property say it's urgent or I should send a color red and when you connect to that property it will actually change the color of your label to red just because the view model would have done that math magic there so that's kind of the idea there is a lot of work to make that work smoothly and provide interesting model so we want to have all the network thing I mean JSON, RPC and what not so that are like more long term work that need to be done on the short term we have been working already on improving documentation tutorials so we already have documentation being written for C and we have been organizing our website to support more language also for tutorials so you have all the reference API that will be generated for your language in what your IDE expect and everything but it will also be online on our website and we also are trying to get space for tutorials on our website for every language we really want to make sure that whichever language you are using you should be able to find an easy and be able to figure out how things are working without having to understand how C work so we are organizing the website the way we generate documentation the way we maintain it hopefully all of that work together well one of the problem with all of this tutorial on things is that basically it's code on the website and code on the website is not compiled by any tools and so one other thing we are really trying to improve is making sure that all of this code is also part of the continuous integration system and we have tests covering all of that which is another level of challenge because they are in different language and things like that so it's not really well when you have been doing a test for C that's not the same thing for JavaScript and so there is a lot of questions that are still open there and also a lot of this tests are actually visual so it's not just because it compiles that it works you want to actually execute the test and see how it does render on screen and how it does behave with input and things like that so there is a lot of work going on on how to improve the way we do testing that is for the integration testing with the EO language we have received some proposal to actually have some kind of automatic testing of the API itself by defining pre-condition and post-condition for every API in the EO file so basically when you look at your API you say you can get an int but you don't know what the range of that int is going to be and you also don't know how it will affect all the property on the object and so one of the idea that has been proposed is to have pre-condition and post-condition that will actually generate test code that will actually be run and we'll be checking if when you do this value in that range it does behave as the API say and that will actually help us have more automatic testing of for API so that's also an area that is long-term research and work at the moment obviously one of the big things we want is parity feature parity on a widget with legacy so this is a big problem because we don't want to just take a feature and put it into a widget in the new API we have to think twice about why is this feature there how is it used and depending on how it is used actually maybe it's a completely different widget that we need to implement on the other side so it's not as trivial as to say okay we need to just copy all of this API and put it there there's a lot of thinking that need to be done and that has been also slowing us down more than we expected because we have to think about the user a lot and how they are using current API so it's one of the things that Samsung has been helping us quite a lot there because we already have a lot of user internally and so we can go around and say how do you use that widget how do you use this API and sometimes it's really silly we have all of this vector graphics canvas it's really optimized really a lot of work to get it there well the only thing they do with it is draw a rounded rectangle that's it they do a rounded rectangle for buttons and that's the only thing they do with it so it doesn't make sense to actually expose this kind of feature and try to put a lot of thought into making things more powerful there because if the only thing they need is rounded rectangle then we're pretty much done there so there's been a lot of these things going on trying to figure out what the user are doing what they want to do and where we are going and I am running towards the end of my talk and so if anyone has any questions sorry so we do have first we have two layer of graphical back end we have the acceleration layer so I will say that's software which we have software which is optimized for neon all the Intel, MMX, SSC and all the families there we have GL and GLES support we don't have Vulkan at the moment there one of the reasons we are not supporting Vulkan and we are not for the moment is that we could not import texture from another application into a Vulkan texture and I think it's doable with 1.1 but I have not looked enough I have just erred it with doable but without that we cannot make enlightenment work and we don't really expect a lot of benefits from Vulkan on our side we are pretty much not CPU nor GPU bound in most of our rendering EFL the only gain we will have is if we are able to save on battery usage so and it's not really obvious how to do that because Vulkan is very powerful when you do multi-threading but if you do multi-threading you may actually do too many of them and start to ramp up the frequency and so it is not a trivial task for context so that way we are not doing it and then we have the other layer for the backend which is the display system so here we have X11, we have Welland, we have SDL we have Apple, macOS 10 I don't know what it is we have Windows we have DRM, KMS DRM we have just frame buffer I think that might be it I'm not sure, maybe missing some but yeah, give you an idea you have a question Gustavo has been pointing out a lot of optimization there, a lot of design that was done in the MVC with Elevate we have kind of, yeah, we have merged a lot of the design there the way it works now is you have a property get that is actually synchronous and you have an event that tells you when a property has changed on your model and the model view and the model have the same API so basically you don't really from the view the view itself you have only one API to handle which is connecting to a property and watching the property change or not and that's pretty much it on Enlightment website on Enlightment.org itself so we did look at other language and we did a survey of everything we could find and nothing was meeting or need and we wanted to I forgot about that we wanted to generate the C++ binding as a fully static either so that when you actually compile your C++ application at the end it only depends on the C API and if you change anything on the system there is no component in between so the C++ will be basically directly using the C API without any overhead and no no code into library in between and to do so we needed to be able to do static generation of this either at compilation time and we realized from that starting point that we wanted on language which is early on to generate all of that any other question ok thank you and good luck for the game