On Fri, 29 Jul 2016 10:41:14 +1000 David Seikel <[email protected]> said:
> On Fri, 29 Jul 2016 08:22:51 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > On Thu, 28 Jul 2016 14:55:46 -0700 Cedric BAIL <[email protected]> > > said: > > > > > Hello, > > > > > > I came to realize that splitting this 3 components don't really make > > > any more sense. If you want to build anything on top of efl, you are > > > > i totally agree. in fact if we are going to merge... we should do a > > lot more merging. we need to decide on a future much smaller set of > > libraries > > > > e.g. (lib* assumed) > > > > efl: > > eina, eo, ecore, efl, eio > > > > eflgui: > > evas, edje, emotion, elementary, ector, ecore_audio, ecore_imf, > > ecore_imf_evas, ecore_input > > > > eflnet: > > ecore_con, ecore_ipc, eldbus, ecore_avahi > > > > eflsys: > > ecore_file, efreet, efreet_mime, efreet_trash, elocation > > > > others left over to figure out... > > ephysics, eet, elua, embryo, eolian, ethumb, ethumb_client > > > > and definitely unportable or dubiously universal lib api's: > > eeze, ecore_drm, ecore_drm2, ecore_buffer, ecore_cocoa, ecore_fb, > > ecore_psl1ght, ecore_sdl, ecore_wayland, ecore_wl2, ecore_win32, > > ecore_x, elput, escape, evil > > I think you left out evas_3D, though I'm beginning to suspect I'm the > only major user of that outside of Samsung. Cedric mentioned that I > might be. it is part of evas already. so included under evas. > Eet should be part of the efl library, it's a basic part of the system, > the data format used by most everything else. Eolian is basically part > of eo, it could join it in efl. On the other hand, it's more a tool > than a library? eolian tho is not used at runtime. only for code and doc generation... thus i left it out. eet is indeed core... today. but it has some issues. we still end up having to allocate masses of ram to decode data. we can mmap strings directly BUT realistically i never imagined our edje objects and files would become so big. they are huge. we eat up multiple MB of data in an app just for this. at least 100's of Kb for sure. and every app loads/decodes the same stuff into ram from the eet file. what I need to do is work out something new. something that: 1. actually isn't a flat key space. the keys in eet files are actually using a lot of space as they redundantly encode a parent namespace, so make it a tree to avoid this. 2. all of this data should be mmaped directly from the file and accessed directly without decoding anything to ram at all. all fields used on the fly. for the above directory structure etc. 3. actual data structures should be accessed directly as mmaped data form the file and NOT decoded into ram first. mmap them in place and come up with some magic to be able to access them as if they were data structures somehow (macros of static inline funcs of some sort). we'd then not have pointers but OFFSETS. every piece of data is "it's located as offset X in this file". this on 64bit will drop memory needed as now we don't use 64bit anymore (well unless we want eet files > 4GB...). I was mulling some kind of variable sized encoding of values so as long as the data only needs 1 bit, it can become part of a flags region of the mmaped mem with 1 bit masked out. same for other numbers (chars, int's, shorts, longs, long longs etc.) - encode things in some way where it'll only use the bits needed. etc. etc. - i haven't thought it out fully yet, BUt this needs a redesign to really address the scaling issues we have now. eet was great when things were small. not anymore. :( > Embryo should be elfgui, it's all about GUI stuff, and again a basic > part of the system used everywhere. Ethumb and ethumb_client also the ONLY thing that uses it is edje. nothing else ever has... so i was wondering where it fits. ethumb i think needs a redesign from scratch and so i was separating it out like we did with e_dbus after 1.7. anything i think may need a replacement in the future i was separating out. > could be part of eflgui, since ecore_audio is. Evas_3D probably belongs > in eflgui as well, and I understand there may be some linking of > evas_3D and ephysics at some stage, so they might go together. ephysics has some memory issues atm and it really needs to probably become a loabable module or simple efl (edje specifically here) will dlopen libephysics on demand only when needed. https://phab.enlightenment.org/T4227 about 72Kb there just to link it in and never actually use it (for ephysics and it's dependencies). per process. thats private dirty pages. thus things that are used rarely shoduld be split out or somehow made to only dynamically link on demand when used. > The unportable ones could all get lumped into a portability library, > though obviously not all at the same time. B-) yeah. the likely would stay very much as is just change name > Eeze in eflsys maybe? it isn't portable tho. it's really linux only. it's api doesn't abstract enough. > Elua I haven't played with yet, it was lacking docs and examples last > time I looked, and I didn't have the time to grok the source code. So > not sure where it belongs. > > I don't even know what elput is. for running against drm/kms framebuffer and getting input devices directly. e uses it. its like the input part of ecore_fb. needed if you want to run terminology or efl apps directly in the fb but in drm/kms mode not fbdev (ecore_fb) > You are probably well aware of my thoughts about efreet, so I wont > mention where I think it belongs. lol it likely needs to also get abstractions BUt it does actually work for open source tools/code across linux's, bsd's and even osx for the open source stuff. but windows is a different issue and ultimately i think this needs a higher abstraction layer and a new design that is at the api and functionality level abstracted from FDO but has an FDO data backend to import/update FDO data into a neutral data store we can use. then add back-ends for windows and osx and whatever other OS needed too. > On the other hand, your suggested tactic for those of us that need to > squeeze the libraries down to a bare minimum set, is to build the lot, > but don't actually install the ones not needed. This merge idea makes > that all but impossible I think. We may need to rethink that tactic. correct. BUT see the above bug report on mem usage. we just have TOO MANY libraries they consume too much actual RAM because there are just so danged many of them. > Though my main need for that is in an embedded project that's going to > stick with an older version of EFL, but I recall there where other > people with that issue. that old tactic just doesn't really scale. this applies to embedded too - this consumes ram on embedded. every new mapping is a rounding error of maybe 1/2 a page per mapping. > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
