On Fri, 29 Jul 2016 10:40:35 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> 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. Cool then. > > 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. :( Rewriting eet is a whole other subject, might be better to start a new thread about it. For my (not small) SledjHamr virtual world project, I want to use some sort of fast and compact representation of all the world data. My initial thought was to try eet, a custom binary protocol I have half designed, and Lua scripts that have been compressed. Actually, I'm using Lua scripts as protocol / file format for prototyping things, but Lua is going to be a big part anyway. I'll benchmark them all, see which works best. I want to store all this data in whichever format works best, and use the same format for the network protocol. My custom binary protocol could be used as this eet rewrite. It's fairly generic, since virtual worlds deal with a world full of random data types and structures. I haven't gotten far enough yet with anything that it's set in stone, so I could easily re-aim it's design a little to be new eet. I'm gonna write my custom binary protocol anyway, based on EFL goodness, so might as well coordinate with you and have it do both. Alternatively, I'll add new eet to the list and benchmark it as well, if someone else writes it. I also intend to write wrappers for my fast, compact, binary protocol, coz every one else wants to use bloated human readable protocols. My main goals are to be faster, smaller, and better than Second Life / OpenSim, yet still be backwards compatible. I could throw in an eet wrapper as well, for EFL backwards compatibility. B-) > 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. Can we do more than just images this time? Thumbnailing large 3D objects into a tiny copy that rotates in a file requester is something I want to do, or an ordinary 2D thumbnail at least. B-) > > 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. Ah, I forgot about the Bullet library. 3D applications might be needing physics, certainly mine will, and Bullet works for me. There will need to be some integration between some sort of physics system and Evas_3D. I can see two separate physics engines though, a full one like Bullet, and a simple one for basic stuff like not falling through the ground or walking through walls. The simple one we could merge, the full one leave separate. > > 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) Ah, I've not used drm/kms, though I have used fb, so that's why I wasn't familiar with it. > > 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. I'm happy to resurrect my old FDO code, and beat it into that sort of shape. I also wanted to have a higher abstraction, and actually use it in E, importing FDO or other stuff. We are on the same page here. B-) > > 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. Yep, so we need a new solution. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
