Stable versions of what? Bodhi currently uses EFL 1.7.5 and the stable E17 release.
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
