Hi Jeff, On Wed, Jan 23, 2013 at 5:29 PM, Jeff Hoogland <jeffhoogl...@linux.com> wrote: > I understand all those reasons, the difference is I'm just going to have to > start telling people like this -> > > http://forums.bodhilinux.com/index.php?/topic/7701-enlightenment-cpu-usage-at-98-on-intel-i810/ > > That they simply can't use E17 because it will eat all of their CPU all the > time with compositing :-/ > > Personally I use compositing on all my system, it looks great in general.
What about stable versions? -- Ulisses > On Mon, Jan 21, 2013 at 10:26 PM, Carsten Haitzler > <ras...@rasterman.com>wrote: > >> On Mon, 21 Jan 2013 10:51:01 -0600 Jeff Hoogland <jeffhoogl...@linux.com> >> said: >> >> > Raster had mentioned on IRC last night that compositing had become >> > non-optional in SVN builds already. What is the reason for this? I >> > understand compositing is the future - but forcing it on everyone it >> going >> > to make E much less usable on legacy hardware - a place where it really >> > shines. >> >> reasons: >> >> 1. aesthetics. having to "design" for both compositing and non-compositing >> is >> limiting and painful. >> 2. code simplification - this cuts down mem usage and resource usage where >> we >> make non-compositing code paths redundant (never loaded) or even get >> totally >> removed. it also makes e and efl's code MUCH easier to maintain as we cut >> out a >> whole class of pain. >> 3. if you do non-compositing, then your other option is avoid anything that >> isnt a pure rectangle.. or use shapes... do u have any idea how inefficient >> shaped windows are? do you know how they are implemented? compositing is >> MORE >> efficient than shaped windows except for the most trivial shape cases. it >> also >> has fewer artefacts. don't make me do a rundown on the actual >> implementation of >> xshape etc... i have little enough time as-is. take if from someone who >> started >> doing x shape stuff back in 1996... >> 4. wayland - we cant sensibly become a wayland compositor without ALWAYS >> compositing. >> 5. compositing only allows us to move content out of windows (eg the >> container >> bg window that holds a canvas with wallpaper and your efm icons etc.) and >> merge >> it into the COMPOSITOR canvas. this reduces mem footrpint drastically - >> example. you have a 1600x1200 screen. you have a 1600x1200 walllpaper. e >> will >> keep the rgba pixels for that wallpaper inside its memory because it >> renders >> them to the bg canvas with software. this bg canvas is a window..that is >> composited.. this means this window consumes at least 1 pixmap of memory... >> that means 1600x1200 (8mb) for the original PLUS 8mb for the composited >> pixmap.. to store essentially the same content PLUS some icons. if we move >> it >> into the compositor canvas we get: >> >> 1. wallpaper image is rendered and scaled by the same enigne as the >> compositor >> (sw or gl). >> 2. only the original wp image is needed, not an intermediate window >> pixmap. we >> save 8mb of memory insnantly. >> 3. evas already has caches for scaled data and can throw out original data >> etc. >> so we also recycle this infra directly. >> 4. "animated" wallpapers now get faster as they render with gl... as do >> wallpaper transitions etc. >> >> repeat for everything else in e17... it all goes into the compositor canvas >> EXCEPT "window content" (client windows - be they e's internal dialogs or >> external apps - to e's compositor these will just be image objects - they >> currently are, but they also include the frame window sections >> (borders/titles) >> provided by e - these will be split out to live in the canvas). >> 6. if objects move into the comp canvas - like window borders, menus, >> shelves... we solve the clipping problem. right now borders, shelves, menus >> etc. get clipped by their window. that's life. once they live in the comp >> canvas they can extend beyond their object bounds (add glows, shadows, >> other >> effects or pixels/imagery extending beyond their bounds). this comes for >> "free" >> when moving into evas and out of a window and that is part of the plan - to >> migrate content all into the compositor canvas. >> 7. i can go on... (tldr time - you asked "why" so read, or never ask again >> :)) >> this has been talked about a lot amongst devs already. it's not possible >> to do >> non-compositing AND compositing and move forward. we have little enough >> developer resources as-is. this simplifies and allows us to have a future. >> the >> fact that we BOTHERED to have fast software compositing is a big part of >> the >> commitment to make compositing work for EVERYONE - you DONT need a >> "supported >> gpu + driver" to use it. yes - it means extra system load, and slowdowns >> for >> those avoiding compositing now entirely - but that's the price of progress. >> we've "lowered" the cost, but it isn't "free". no one is totally LEFT OUT. >> the >> software compositor works even in 16bpp (with extra overhead though). and >> 8bpp .. well ok - sorry 8bpp people. if you can only do 8bpp then we're >> leaving >> you behind. sorry. 1995 will be happy to keep you. :( we CAN reduce >> overhead of >> software compositing still - it's heavy because we HAVE to copy pixels >> from x >> (read data via x(shm)getimage). we can't fix that unless we can get a >> zero-copy >> path. x allows us no such path for software (shared pixmaps are not an >> option >> fyi). we COULD shortcut this path - but we need to do it at BOTH sides of >> the >> pipeline. that means modify toolkits/apps. we CAN modify efl to bypass x >> entirely for rendering and only use it for focus/input/events and use a >> back-channel shared memory system to export pixel buffers direct from >> client to >> comp. it's doable. we'd cut overhead in half for copies as we... get rid of >> them (we only have now rendering overehead). *IF* comp also bypasses x's fb >> management and goes direct to fbdev or kms... and does evil stuff... we can >> ALSO make "rendered pixel uploads" totally free. ie zero copy buffer >> swaps. - >> then the ONLY overhead we have is filling the comp "backbuffer". what you >> may >> not be aware of is.. evas ALREADY has this infra. it can already do this >> little >> zero-copy buffer swap trick... all the code is there.. it's even been >> tested >> with real drivers that do support this - there is even a virtual buffer >> swap >> emulation layer to test it if you don't have such a magic driver.... >> BUT... it >> requires driver work to make this possible - or bypassing x's fb driver >> entirely... but we can already do this kind of stuff. we're FAR from >> maximum >> optimal level in sw compositing. in fact if we did both of the above for >> things >> like scrolling your browser window around we'd basically increase >> framerate by >> 3 times compared to now. that's our existing potential upside if we plug >> all >> the bits together. we're far from pure ultimate potential, and even being >> far >> from it.. we are very usable on low end systems. so without a gpu to >> accelerate >> it all and make it all zero-copy... we have a potential upside (for efl >> apps) >> of up to 3 TIMES faster (and a minimum of 2 times faster). for non-efl >> epps up >> to 2 TIMES faster. though at this point.. we're almost being a wayland >> style >> compositor directly, so i'm wondering if we'll ever bother with x stuff to >> optimize this far and just jump to being wayland from there, as wayland is >> all >> about sending buffers around and avoiding copies... efl already lends >> itself >> very well to this. it already has the start of a wayland port and a wayland >> compositor in e17. and as above... we cant move to doing wayland stuff >> unless >> we move to being "compositing only". keeping mind "compositing only" does >> not >> EXCLUDe optimizations like "zeo copy/composite" you do for things like >> fullscreen windows (games etc.). if you do this just right you can take the >> client pixel buffer it sends you (it sends a handle to it - it doesn't >> COPY it >> to you) and you just program the gfx chipset to pint the real hw buffer >> scanout >> to the client buffer. ALL the compositor is doing is updating where the fb >> points to... it's doing zero actual compositing/copying/blending work in >> this >> case. its turles... err.. zero copy all the way down. so your games are not >> affected at all. if at any point some menu or dialog appears on top.. it >> begins >> compositing again for that frame on until that overlayed window goes away. >> given smart enough compositing and the right hardware you can EVEN avoid >> compositing in such simple scenarios.. a lot of hardware supports RGBA >> OVERLAYS >> - multiple buffers blended on top of eachother. your hw mouse cursor is >> exactly >> such an overlay buffer. "xv video acceleration uses such a wh buffer often >> too >> - but its yuv, not rgba... but same principle. a smart compositor can >> PROGRAM >> the overlay buffer to point to this "popup menu/dialog" and keep the 2 >> framebuffers totally separate... zero compositing/copies... until the 3 of >> windows becomes too complex to point directly at hw buffer layers, then it >> has >> to start compositing for real... my point here is... this is the path we >> MUST >> go down. we NEED to. wayland is being designed for this.. and they're >> right. >> this is how u get zero-tearing smooth screen updates with minimal overhead. >> it's a fundamental shift in perspective from copying pixels to a single >> shared >> framebuffer with clip rects, but it is the reality of most hardware you >> already >> have from phones through to set top boxes, tablets, laptops and desktops. >> you >> just don't know it. most of these capabilities lie idle and unused because >> our >> display system is too "old school" AND because of nay-sayers holding back >> progress saying "waaaa - i don't want compositing!". reality is that >> basically >> anyone who KNOWS graphics, hw and infra all the way down to these nuts and >> bolts is already in agreement - this is the way to go. we agree because we >> know >> what is actually going on behind the scenes. the decision to be compositing >> only is a big step - but in the right direction. suffice to say, that if >> you >> don't "get it" now, in a few years, you will. the penny may drop. maybe for >> some it won't - you may be the same people who think a green screen vt100 >> is >> all u ever need. pixels are useless. color is a waste of memory. reality >> is... >> sticking to non-composited displays is as useful as sticking to a vt100 >> attached to a 192000 baud serial line. :) >> >> -- >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- >> The Rasterman (Carsten Haitzler) ras...@rasterman.com >> >> > > > -- > ~Jeff Hoogland <http://jeffhoogland.com/> > Thoughts on Technology <http://jeffhoogland.blogspot.com/>, Tech Blog > Bodhi Linux <http://bodhilinux.com/>, Enlightenment for your Desktop > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
