Re: [e-users] Non-Optional Compositing
On 01/23/2013 08:29 PM, Jeff Hoogland 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 :-/ Hi In *composite settings*, you can choose *none* everywhere. Its' much better for cpu consuming -- Maderios Art is meant to disturb. Science reassures. L'art est fait pour troubler. La science rassure (Georges Braque) -- 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
Re: [e-users] Non-Optional Compositing
It would appear that on Jan 24, Carsten Haitzler did say:
its a simple radiobutton selection list in the composite settings - software
or
gl. you can choose (if you have the choice :) - otherwise you'll just get
software).
there are 2 hiccups. 1 - it goes BACK to software even if you had gl enabled
and a separate issue 2. the use argb iwndow option changed to be use
shaped window: and in the process seems to have flipped value and shaped
windows with comp cause much unhappiness.
Well from my point of view then it's all good...
What ever settings I might have are simple... (sounds like the hard stuff
will be up to those who do things like create themes etc...)
And the only thing I might really need to remember is that I might {just
maybe} need to toggle a setting labeled shaped window...
Done worrying!
Thanks for the explanation.
--
| --- ___
| 0 -
| ^ JtWdyP
|~\___/~
--
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
Re: [e-users] Non-Optional Compositing
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.comwrote: 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
Re: [e-users] Non-Optional Compositing
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.comwrote: 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
Re: [e-users] Non-Optional Compositing
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.mobiwrote: 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
Re: [e-users] Non-Optional Compositing
It would appear that on Jan 23, Jeff Hoogland did say:
I don't plan to stick with this release snapshot forever though. I'm
also assuming we will be seeing new E17 snapshots sometime before
another decade passes to address bugs in the release.
Eventually compositing only will be the only option.
As a guy who always thought E looked plenty great {even without composting}
I've no use for transparent windows, and so forth, so I've never used
composting...
Assuming my hardware can handle it, will my transition be automatic or
will I need to learn how to configure it, just to keep things working???
If so is there a beginners tutorial/howto laying around?
--
| ~^~ ~^~
| ? ?
| ^JtWdyP
|\___/
--
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
Re: [e-users] Non-Optional Compositing
On Wed, 23 Jan 2013 13:29:51 -0600 Jeff Hoogland jeffhoogl...@linux.com said: compositing is the problem is entirely wrong. http://www.enlightenment.org/ss/e-51007211524a49.09575794.png pentium-600, 2 terms, 1 with animated blinking cursor, other running top refreshing every second. so its far from idle (it'll be generating frames probably 50% of the time. e is using 2%... terminology is using more than 2x what e is to rendering its terms... and x as well (having to copy pixels to pixmaps and allow e to read them back and then copy pixels to the screen from e's comp when composited). software compositing. 98% cpu usage is something else. something continuously animating AND rendering. something likely large. it may re-draw the exact same thing every frame... so you dont know - but it is. maybe its some totally other bogus thing spinning nothing to do with comp at all. maybe the blacklists in evas haven't detected a software gl implementation (they do have specific tests for it). i810 cant do gl with evas. too primitive, so *IF* they are using gl... and somehow evas is not failing, they have gotten themselves a SOFTWARE gl rasterizer.. and THAT is going to eat cpu until the cows come home. i'd love to know the gl vendor/renderer/version strings for that driver so i can blacklist it (glxinfo). until then - they should switch to SOFTWARE. that is assuming its comp + gl + software gl. it could just be a poor theme. something with lots of shaped windows. shaped windows are evil and comp gets a bunch of extra overhead - even with gl, to deal with them. ARGB windows are fine (though now comp needs to alpha blend vs just blit/copy). there ARE situations of high cpu usage even with gl - nvidia closed binary blobs have in recent times regressed to polling spinning gpu/vblank sync - they dont sleep waiting for the gpu to screen retrace to begin, but SPIN in a loop thus consuming 100% cpu - this is a DRIVER bug. on weaker gpu's e will use massively less cpu than on these nvidia+high powered gpu combos when rendering. older drivers were much better behaved. i have yet to get around to filing a bug on this as i need to sit down and actually prove this before filing and identify the exact point with some debugging code (a bit of /proc trawling around glxswapbuffers etc. should do the trick). 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.comwrote: 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
Re: [e-users] Non-Optional Compositing
On Wed, 23 Jan 2013 17:19:59 -0500 JtWdyP jtw...@ttlc.net said:
It would appear that on Jan 23, Jeff Hoogland did say:
I don't plan to stick with this release snapshot forever though. I'm
also assuming we will be seeing new E17 snapshots sometime before
another decade passes to address bugs in the release.
Eventually compositing only will be the only option.
As a guy who always thought E looked plenty great {even without composting}
I've no use for transparent windows, and so forth, so I've never used
composting... Assuming my hardware can handle it, will my transition be
automatic or will I need to learn how to configure it, just to keep things
working???
If so is there a beginners tutorial/howto laying around?
1. you dont need your hardware to handle it... software compositing is an
automatic fallback if gl is selected but fails to init. the default is
actually software, and the wizard in e17 poked around your xorg logs to try
figure out what gpu/driver you have and tested if gl engine works.. and if this
was whitelisted it automatically suggested using gl.
its a simple radiobutton selection list in the composite settings - software or
gl. you can choose (if you have the choice :) - otherwise you'll just get
software).
e in svn already has compositing in core. you dont need to do any
configuration... its on all the time. you cant unload or turn it off at all.
there are 2 hiccups. 1 - it goes BACK to software even if you had gl enabled
(simply a config migration issue during development - we'll fix this up before
e18 is out to enure if you HAD gl.. you still have it for e18. those living off
svn of course get to enjoy the hiccups). and a separate issue 2. the use argb
iwndow option changed to be use shaped window: and in the process seems to
have flipped value and shaped windows with comp cause much unhappiness.
--
- 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
[e-users] Non-Optional Compositing
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. Cheers, -- ~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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Non-Optional Compositing
On Mon, 21 Jan 2013 11:08:08 -0600 Johnny Lee runt...@gmail.com said: this is non-negotiable. sorry. there is a software compositor - its far more usable than any gl software fallabcks. enjoy it. and don't tell me it's slow. it oh most DEFINITELY is not: http://www.youtube.com/watch?v=ESwhnWM1cKw penitum-m, @ 600mhz (locked down to lowest clockrate), 512m ram 1024x768. software compositing only. zero acceleration. sure - not silky smooth in all cases... but usable. if it's slower than that on an equivalent machine you either have enabled smooth scaling for windows in comp, or have x driver issues and may want to consider using a simpler driver like fbdev as opposed to an accelerated x driver. I have to agree with Jeff on this. Most of our users ( Macpup ) have older hardware that can't run compositing. On Jan 21, 2013 10:52 AM, Jeff Hoogland jeffhoogl...@linux.com wrote: 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. Cheers, -- ~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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- - 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
Re: [e-users] Non-Optional Compositing
Hello, On Tue, Jan 22, 2013 at 1:51 AM, Jeff Hoogland jeffhoogl...@linux.com wrote: 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. I have been using composite on a EEE 701 PC for years now. It's fast and nice there. So I have some doubt on getting E much less usable on legacy hardware. You will have to define it. More over moving to always composited open a lot of possible optimization to reduce memory usage and cpu usage that is just insane to do now. -- Cedric BAIL -- 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
Re: [e-users] Non-Optional Compositing
On Tue, Jan 22, 2013 at 2:08 AM, Johnny Lee runt...@gmail.com wrote: I have to agree with Jeff on this. Most of our users ( Macpup ) have older hardware that can't run compositing. That's why we have software compositing and please define hardware that can't run compositing. -- Cedric BAIL -- 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
Re: [e-users] Non-Optional Compositing
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
