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. 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
