Hi, On Wed, Jan 23, 2013 at 5:38 PM, Jeff Hoogland <jeffhoogl...@linux.com> wrote: > Stable versions of what? Bodhi currently uses EFL 1.7.5 and the stable E17 > release.
With those versions you can disable compositing, right? -- Ulisses > On Wed, Jan 23, 2013 at 1:34 PM, Ulisses Furquim > <ulis...@profusion.mobi>wrote: > >> 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 >> > > > > -- > ~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
