On Mon, 5 Apr 2021 13:15:46 +0900 Florian Schaefer <list...@netego.de> said:
sharing again in the name of making it easier so you understand why things are done how they are - they are both usability and performance and distribution considerations here. fyi - the default theme is about 17-19m (depending how it's compressed). if you unpack it like a web page will be on disk with all images and css/html etc. as files... the default theme expands to 60m ... edje_cc's job is primarily to compress to a much smaller format and also make it all a single file to drop into your theme dir - so for end users of themes installation is as simple as popping the file in a dir (system or user themes dir as per previous mail) and then selecting it. themes (edj files) are mmaped and then specific segments are accessed on demand as needed at runtime with their content being decompressed (and cached) on the fly. like previous mails - caching is all over the place and things will sit decompressed in ram until they drop out of cache base on lack of use. only the parts of the file that are needed are accessed so you will see memory profiles may think efl/e apps use more ram than they do because they all go mmap the same theme edj file (and thus these all share the same pages on a system and there is only one copy in memory shared across all the processes that use that theme file - and only the active pages in that file are in memory). the default.edj the efl source tree builds is about 19m (vs 16m if compressed with default compression that will happen with the build.sh that is written unless you provide different options) - it uses a less efficient compression scheme than the default edje_cc uses (the default is gzip level 9). the efl build uses -fastdecomp which is lz4hc. it's decent compression levels (about 80-90% as good as gzip) but decompression is like about 10 faster than gzip, so thus it's chosen for performance but to give up a little size. still - it's all about making that theme small, compact and a single drop-in file that needs not installing unlike most other theme systems that require you unpack it all to disk to use it, this people ship themes as zip, tar.gz, tar.bz2, etc. files and you have no standard archive and transport format. with edje i created a standard format that does not need to be tarred/zipped or made smaller - it already is. it doesn't need installing beyond dropping in the right dir. the result of this is modification requires then unpacking it with edje_decc... and then packing it back up again with build.sh for use... if you develop a theme you can leave the source unpacked and just run the build for use of i, but this is built around the fact that for every person hacking on a theme there are 1000's of users who never touch it, so optimizing for the majority use base at runtime. so now you understand the choices made. it may, at the beginning look like you can't mess with a theme - it's "some binary file". that view is one of just not being used to this, like a new user to linux might struggle to understand they often need to run vi to modify config and don't have some clicky-pointy dialog with checkboxes. same logic here - once you just know about the tool (vi, or nano or emacs or ...) you then can do things. here - edje_decc is your tool and friend. it's no different than learning to use tar or unzip or vi or emacs.... :) if you really want to dig - edj files are just eet archives. eet -l file.edj will list all the keys in the archive (like tar ztf file.tar.gz or unzip -l file.zip). it will list about 6000 keys in the edj archive for the default theme. it's far more efficient to store this in the edj file than out on disk - far more efficient. you CAN try extract specific keys. if you want to know more about the eet tool just run it with no arguments: eet Usage: eet -l [-v] FILE.EET list all keys in FILE.EET eet -x FILE.EET KEY [OUT-FILE] [CRYPTO_KEY] extract data stored in KEY in FILE.EET and write to OUT-FILE or standard output eet -d FILE.EET KEY [OUT-FILE] [CRYPTO_KEY] extract and decode data stored in KEY in FILE.EET and write to OUT-FILE or standard output eet -i FILE.EET KEY IN-FILE COMPRESS [CRYPTO_KEY] insert data to KEY in FILE.EET from IN-FILE and if COMPRESS is 1, compress it eet -e FILE.EET KEY IN-FILE COMPRESS [CRYPTO_KEY] insert and encode to KEY in FILE.EET from IN-FILE and if COMPRESS is 1, compress it eet -r FILE.EET KEY remove KEY in FILE.EET eet -c FILE.EET report and check the signature information of an eet file eet -s FILE.EET PRIVATE_KEY PUBLIC_KEY sign FILE.EET with PRIVATE_KEY and attach PUBLIC_KEY as it's certificate eet -t FILE.EET give some statistic about a file eet -h print out this help message eet -V [--version] show program version eet itself won't actually extract images to a png/jpeg and it cant ENCODE these formats. edje_cc does this by using evas to do this work (also to decode png/jpg etc. files before encoding them into the eet file in eet's own custom image encoding formats). eet + edje support som exotic encodings that are very GPU efficient too - i'm not using them (yet - will eventually for wallpapers) as these will actually mean at runtime your gpu will use less memory for the default wallpaper - this speeds up rendering and cuts memory usage. these will use about 1/4 the memory of the raw rgba data if i switch to use them and speed up rendering as simply less memory (1/4 as much) is accessed when drawing the background for example. now all of this above explains why you have these "un-unix philosophy binary files". well it's un-unix if you include tar.gzip as uni-unix philosophy... :) as an aside - all those .cfg files in ~/.e/e/config/* ... those are also eet files. they do the same thing edj files do. they encode data structures to/from memory into a compressed binary file - eet can actually decode these and poke around inside and insert data - this is done to generate the default cfg files on the system as part of the enlightenment build - the build files just run eet (the cmdline tool) to generate the cfg file from text sources. you can also use the eet tool to poke around the cfg files. vieet is a shell script wrapper around $EDITOR and the eet tool to edit cfg files... all you need to know is that tools exist and what they are. 99.9999% of the time you never need to know or even care... sometimes it's useful. without eet e's cfg files would be significantly larger, take longer to save and longer to load. (my e.cfg file goes from 63kb to 728kb of config when extracted to source text that looks a bit json-ey). it's 16500 lines of config file... i did an analysis of this back in 2013: https://phab.enlightenment.org/phame/post/view/12/eet_compared_with_json_-_eet_comes_out_on_top/ xml would be worse than json of course. again - reasons why we do things and we have tooling to make this possible to manage. loading configs in for things like e is on the order of 7-10 times faster with eet vs if this were to e.g. be json. it means we have an entire different view of the cost of these things and we can do them more as they cost much less. e is writing out configs quite often because it's so cheap to do. these days git e actually even just punts it off to a thread so it doesn't even stall the main ui. as you may notice, we re-use eet for a lot of things. it's well tested and beaten into shape. i could do better of course these days, i think. i invented eet almost 20 years ago or so... i've learned a few things since, but given the age of its design, i think it's not too bad. sure. you could say "i don't care about performance - i just want things done the unix way because the unix way is my god", in which case e may not be for you. it is anti-unix. it doesn't break things up into lots of tiny processes with pipes and what not gluing them together. it takes a monolithic approach - modules for expansion (like the linux kernel) and a very integrated single process (as much as it can manage) approach. this leads to e's memory footprint being tiny compared to all the desktops of equivalent functionality, and e's startup being pretty much at the top level (fast) given how much it does etc. ... a lot of decisions in design have been made in the name of performance and efficiency. sometimes compromises are made to trade off some performance for something beneficial. it happens. but remember deep down in e and efl are lots of designs that were made specifically so you can run e on that old machine you have there. sometimes some things just won't be as good as on a newer machine, but overall it should not be bad. i do run e on my rpi3 as an example of "how low can you go". the oldest x86 box i have is this i5-4200u laptop. it's low volt so not that performant and only has 4g ram, but e runs a treat on it. perhaps the slowest x86 machine i have is a single core 1.4ghz baytrail nuc with 2g ram. it's newer than this laptop, but lower-end. it runs the media archive behind my tv, so i don't really run things on it... but i can if needed, but realistically my rpi3 serves as a good enough example of low-end. the rpi4 is a "better arm box" with its 4g ram, but still very low end. i have various other arm systems which are ballpark around rpi3/4 and a bit faster land. i did (until lockdown due to covid) have a 32 core arm base emag system with 32g ram and an amd gpu (it's a server arm chip with proper pci-e etc in a full atx pc case etc. - it was my day to day workstation until i started working at home). that was the highest end arm box i had. my "laptop on the couch" as no one is travelling anywhere is in xps13 from 2018 - so not majorly high end but not slow either (16g ram, i7-8th gen, 1080p). e runs as smooth as a babies bottom on that. i've never seen a more polished linux system - pressing the power button through bios and to desktop in about 8 seconds. no flickering or flashing - a smooth dell logo, that hides, then black, and system just fades into e with the startup splash sound. shutdown is just fade to black then it's off. suspend/resume is a smooth open/close lid and e fades in nicely on resume. my desktop (main system i spend most of my time on) is an amd5950x (16c/32th) + 64g@3600mhz + rx6800xt + a bunch of nvme disk space. it's high end. it doesn't struggle at anything at all. i can build e and efl in a few blinks of an eye. it makes development nice. e works like a charm on this like on the xps13. the only thing that let it down is i can't get rid of the bios logo and the "press f2 to enter bios" text without some custom windows flashing tools. my point is that i have machines on all ends of the spectrum for performance in both cpu and gpu. i try and make sure e and efl run well on all of these. i' m not perfect, but i try... :) > On 4/5/21 2:54 AM, Carsten Haitzler wrote: > > On Sun, 4 Apr 2021 17:40:21 +0900 Florian Schaefer <list...@netego.de> said: > > > >> On 4/4/21 5:02 PM, Francesc Guasch wrote: > >>> On 04/04/2021 05:09, Carsten Haitzler wrote: > >>>> On Sun, 4 Apr 2021 10:20:15 +0900 Florian Schaefer <list...@netego.de> > >>>> said: > >>>> > >>>>> On 4/4/21 5:52 AM, Carsten Haitzler wrote: > >>>>>> On Sat, 3 Apr 2021 17:55:23 +0200 Francesc Guasch > >>>>>> <fran...@telecos.upc.edu> > >>>>>> said: > >>>>>> > >>>>>>> Hi. I am running Enlightenment 0.24.99 24520. > >>>>>>> > >>>>>>> It has always run smooth on my lapton, this is a 2005 Toshiba > >>>>>>> with 4 GB RAM. It sports an Intel Corporation Mobile GM965/GL960 > >>>>>>> Integrated Graphics Controller. > >>>>>>> > >>>>>>> I know I am pushing the limit here, sorry for that. Since the last > >>>>>>> release changing windows with ALT-TAB takes 2 / 3 seconds. After the > >>>>>>> window changes the list of tasks is shown and the back desktop is > >>>>>>> blurred for a few seconds. Then the selected window is shown and I can > >>>>>>> use it. > >>>>>> > >>>>>> how is it blurred. the default theme does not blur the background. i > >>>>>> tried > >>>>>> that a while back in flat but testing on an older machine showed it > >>>>>> could > >>>>>> not keep up (a 2010 intel laptop with intel gpu) and dropped to like > >>>>>> 20-30fps, so i disabled the filter and it just darkens what is > >>>>>> below... so > >>>>>> what you describe must be an altered theme? > >>>>> > >>>>> Sorry if I barge in into the discussion here. Just yesterday I also > >>>>> updated after some weeks again to he current git versions, now with the > >>>>> flat theme, and experienced the same "issue". (BTW, I also ran into the > >>>>> elput issue and had a jolly time figuring out that I need to enable the > >>>>> DRM option.) > >>>>> > >>>>> I guess what Francesc intended was exactly this fading to a darker > >>>>> background. On my machine here (i7-3517U) it takes probably about a > >>>>> second. But it is no smooth transition and rather seems to be stuttering > >>>>> along the way, thus feeling really as if the machine is struggling to > >>>>> keep up with rendering this transition. The effect is that the whole > >>>>> process of switching windows feels very sluggish and seems to take ages. > >>>>> > >>>>> I was also (unsuccessfully) looking around for a way to switch off this > >>>>> transition effect. Switching between windows with Alt-Tab is a very > >>>>> common action and I would like this to be over in literally in the blink > >>>>> of an eye. One can actually quickly switch windows in the current state, > >>>>> cutting the whole transition short right at the start. Still, I would > >>>>> prefer if I can have the window list either appear instantaneously or > >>>>> with a really fast fade-in and -out. > >>>>> > >>>>> (BTW, this is using the window switcher in list mode, not in large mode > >>>>> where this whole background darkening is probably really necessary as > >>>>> there is otherwise no window to separate the list from the normal > >>>>> desktop.) > >>>>> > >>> > >>> Maybe I didn't explain good enough. I reproduce it pressing ALT-TAB > >>> while I have some windows open. I don't know about window siwtcher in > >>> list mode or large mode that Florian talked about. > >>> > >>>>> Cheers and thanks as always for the great work, > >>>>> Florian > >>>> > >>>> also a large number of maximized windows (a lot of pixels to render) > >>>> will slow > >>>> down even the best of gpu's if you have enough of them... smaller windows > >>>> render faster in miniature (the input window is smaller). and both the > >>>> old list > >>>> mode and large mode how show these miniatures and thus render > >>>> everything you > >>>> see which costs.. the more you have visible, the more it costs. it > >>>> costs even > >>>> more in software rendering than a gpu... the "i dont even see the fade > >>>> animation" hints to me it's software compositing or a very large > >>>> number of > >>>> large windows. > >>>> > >>> Hey ! Thanks for stepping in Florian. I was wrong, the problem was not > >>> on the fading of the background, but on the app windows. > >>> I too built with the latest git commits but it didn't fix it for me. > >>> Is it running faster ? Maybe, I am not sure, but it is still slow. > >>> > >>> Right now I have a couple of Thunderbird windows and a Terminology > >>> and it is paifull. Probably because of the large Thunderbird window > >>> that takes all the screen. xrandr shows 1680x1050 60.00* > >>> > >>> Just to summarize: > >>> > >>> - Large Windows: yes, it gets worse with those. But just a gvim and > >>> a terminology also is noticeable slow. > >>> - Composite: OpenGL > >>> . glxinfo: direct rendering: Yes > >>> > >>> And now what may be the root of the problem: Turning rendering to > >>> software or opengl won't make a change. So the conclusion may be this > >>> laptop is way too old. I tried if I could download drivers but the > >>> Ubuntu software tool won't show any. With lsmod I see i915. > >>> I guess 2020 Enlightenment task switch was way faster because it > >>> probably didn't have this transition. > >> > >> I actually made the same observation, software rendering and openGL > >> won't make a difference. I thought this odd at that time. However, now > >> that we know its the previews and not the transition effect, it probably > >> makes sense. Seen that Raster has some dithering algorithm doing the > >> down-scaling its probably down to the CPU to do this. The way you put > >> the result on the screen, software or openGL, won't affect the time > >> required then. At least that's my understanding now. > >> > >> On a different note: I am a bit worried about this "laptop is way too > >> old" feeling. For me one of the selling points of linux in general and > >> also E in particular was and is that it is supposed to also run fine on > >> non-bleeding edge hardware. I am all in for fancy effects where the > >> hardware is capable of doing it but I hope to at least have the options > >> somewhere to cut back on the eye-candy and convenience functions (like, > >> e.g. real-time preview thumbnails) so that the system is still fun to > >> use on less capable computers. > > > > BTW... you could have just removed the swallow for the win miniatures from > > the theme and it'd have been fast again... themes are intended to be > > user-manageable. different to source code. just because you don't know HOW > > to tune something for your system doesn't mean it isn't possible. > > Of course, being open source I can always make any changes myself. > Nothing is impossible. I was even considering that. I am not so sure > whether for E the theme is really different from source code. Theming in > the world of E means learning some special kind of theme programming > language and even needs a compiler to create the final theme file. Isn't > that at least very close to source code? > > Anyways, for the fun of it I now tried to track down where the actual > theme of E can be found. Not an easy task. Indeed, I have to admit > defeat for now. I would have expected to find the source files for the > edj files somewhere around. It seems I am mistaken. > > Also, building a custom theme modification means opening the Pandora's > box to always manually merge my own changes into the changes of the > "official" theme. I am indeed doing this with other projects. Not the > most fun activity (which you have spared me from now) > > Finally, I wouldn't have known that just removing the display bits of > the miniature from the theme would actually also disable the internal > rendering of the thumbnails. It seemed quite probable that at that point > the code just assumed that the miniatures will always be needed and > prepared them in any case. > > OK, enough of that. > Again, I am happy that you made this an option now. :-) > > > Keep in mind that out of the box things are not going to be tuned for > > ancient hardware anymore. It means sacrificing a good experience for those > > who do not have ancient hardware - or well sacrificing the "wow" you get. > > Reality is the people on very old hardware are going to have to do some > > work to turn things off and change settings and tweak. In this cas all you > > had to do wans delete thw e.swallow.win part in the winlist list items... > > and winlist would not have put the miniature preview there. :). > > Once you know exactly what needs to be done it is always easy. ;-) > > > You could argue people with a c64 can't run linux and they will complain > > it's too fat and bloated. There is always someone with old enough hardware > > who will struggle with modern software out of the box. That's life. It's > > why you upgrade your hardware - to get yourself a better experience. In > > fact it generally gets you a better experience and better battery life too, > > given the major advances in power efficiency in more modern systems. The > > systems are capable of doing much more out of the box and also of having > > much better battery usability. Yes > > - it costs money to upgrade. > > > > My advice might be to consider an upgrade just to get a better experience > > anyway. Compiles will be a lot faster. battery life better, and you can have > > more eyecandy ... :) > > Jep, wholeheartedly agreed on that. I am longing for the day that a > "worthy" successor to my venerable but still impeccable Series 9 > notebook appears. > > Cheers, > Florian > > >> Anyway, still a happy user here who is thankful for all the effort of > >> the developers to provide us with a system that I can use both at work > >> and at home for well over a decade now. :-) > >> > >> Cheers, > >> Florian > >> > >>> I really appreciate you took the time to look at this and try an > >>> optimization just for us. Thanks a lot ! > >>> > >>> > >>> _______________________________________________ > >>> enlightenment-users mailing list > >>> enlightenment-users@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > >> > >> > >> _______________________________________________ > >> enlightenment-users mailing list > >> enlightenment-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
