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