On Sun, 29 Jul 2012 20:57:03 -0400 The Wanderer <[email protected]> said:
> On 07/29/2012 08:09 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Sun, 29 Jul 2012 10:43:27 -0400 The Wanderer <[email protected]> said: > > >> I do object in principle to any refusal to allow customization, but I > >> certainly do recognize that practicality must take precedence. > > > > in some cases we have to refuse = because it either makes the code hard to > > maintain or hard to add real usability features. > > Understood. As I said, practicality. > > >> If nothing else, I'm not sure whether to > >> > >> A: list the elements of my preferred configuration (and point out the ones > >> which I haven't figured out how to achieve so far), or > >> > >> B: list specific E16 configuration options which I want/use and haven't > >> found (which might very well miss things, and/or be less effective at > >> explaining *why* I want them, and/or make it harder to spot good alternate > >> ways of achieving the same goal), or > >> > >> C: describe both "how I turn the default E16 layout into what I want" and > >> "how I've tried to turn the default E17 layout into what I want, and where > >> it's fallen short". > >> > >> Which one would be most useful/approachable from your perspective? > > > > just describe what it is you want to do. :) > > The trouble is that there are a few different ways to interpret that. > However, I think option A is probably closest; I'll see what I can do (though > probably not tonight). > > >> Hopefully there will still at least be an option to turn off the > >> "compositing" behavior, if not remove the module itself entirely? (Which > >> I'd still prefer, since it would also reduce e.g. memory footprint, but > >> isn't absolutely required.) > > > > no - there will be no option to turn it off. it will be baked in > > "take-it-or-leave-it". a massive rework of fundamental things inside e will > > mean its a one-way street. we will be removing windows all over the place to > > put the content into the compositor canvas directly as objects. here's why > > this is good: > > > > 1. your desktop wallpaper, shelf, menus, popups, everything, desklock etc. > > now will exist purely in the compositor canvas, not as actual windows - this > > means they wil be rendered with the engine in the compositor canvas... eg > > opengl, and thus accelerated. if not well then it isn't any WORSE that it is > > now... which is software. > > Does the picture change if I mention that I don't use pretty much any of that > except the menus? you use the wallpaper - like it or not. it's always there. :) > Aside from memory usage (which you've presented good arguments on), my main > concern about "fancy visual effects" in window managers is what might be > called "baseline processing load" - the minimum CPU(/GPU/etc.) activity > necessary even for just sitting idle, and for basic tasks like e.g. moving > the pointer around the screen. pointer is not done by a wm - it's done by x itself and either is software emulated (rather hackishly in fact - sw cursors in x are horrible - don't get me started on that/ i'd sooner kill of cursors in x11 entirely and do them client-side in the compositor if i could that rely on x cursors), and hw cursors are literally overlayed by specialised hardware and cursor moves just reconfigure where the overlay is on the screen. they involve no redraws. (except sw emulated cursors ad above, and those are - so horrible, i'd rather gouge my eyes out than look at them). > I have the impression, possibly unfounded, that such requirements are going to > be higher for anything centered around "eye candy" than for something > otherwise comparable which isn't. I reflexively consider "compositing" pure > eye candy, I think since the initial benefits touted from things like Compiz > were AFACT entirely in the eye-candy field. enlightenment exists *BECAUSE* of eye candy. it exists BECAUSE i wanted a wm that has better eyecandy. that is it's reason for living. so yes - eye candy costs something. that's life. :) if i wanted to make a wm that was purely focused on minimal mem/cpu footprint it'd be totally different to e. this is something you'll need, i guess, to accept. that eyecandy is in e's DNA from day 1. of course we try and get the eyecandy so we pay a low price for it, or as low as we can get, but we still pay for it. that's life. > You've presented good arguments as to why memory consumption shouldn't be > increased and might even be decreased by switching over to a compositing-only > model, and that's reassuring. Are there comparable arguments on other resource > usage, such as CPU (and other processor) load? Or is that still essentially > 100% negligible regardless? Or is it in fact a potentially legitimate concern? mem consumption won't go up from current COMPOSITED e17. it's still more than non-composited. but that is a trade-off i'm willing to make. as such a compositing wmm is always involved in all rendering. any app drawing in its window will involve the wm having to re-composite. so it will always cost something cpu-wise. cpuload won't change really from current composited e. from non-composited, it will be more. > Snipping the other points, as I don't have anything to say to them - I do like > the sound of it overall, and I do agree that it's probably the best approach. > I just have my standing concerns about baseline resource consumption, from > what I think might be called a "minimalist" perspective. just a point here - e was NEVER a minimalist wm. it never aimed to be one or make minimalists happy. minimalists are not e's target audience or goal. it just so happens as a bit-product of caring about efficiency that we HAPPEN to make some minimalists happy by consuming less in the way of cpu/ram etc. than most equivalent wm/de's (in terms of features) out there. moving to compositing-only is actually an efficiency thing. if we accept the future that 90% of people will use compositing, then we make things more efficient for the 90% but unfortunately hurt the 10% who don't want compositing. the alternative is we maintain a more complex codebase with more codepaths, fewer of which now get tested, causing overhead in development time, maintenance, more bugs, uglier code, etc. - if it was a 50-50 split, it may not be worth moving to comp-only, but... it's not . it's really 90%+ use compositing. > -- > The Wanderer > > Warning: Simply because I argue an issue does not mean I agree with any > side of it. > > Every time you let somebody set a limit they start moving it. > - LiveJournal user antonia_tiger > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
