On 07/29/2012 10:41 PM, Carsten Haitzler (The Rasterman) wrote:
> 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:
>>> 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. :)
Not in E16, I don't; I set the background to a plain black color, defined using
the "RGB triplet" sliders, rather than to a wallpaper image.
This may be a terminology difference, but I don't consider a non-image
background to qualify as a "wallpaper" - though I can see how it may be handled
the same way in the code.
However, since E17 doesn't seem to support color-based instead of image-based
backgrounds (which would be a negative point in any comparison between it and
E16), this may be somewhat moot anyway.
>> 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).
Acknowledged; it occurred to me after posting that moving the pointer around has
been an essentially zero-load activity for pretty much any system for at least a
decade anyway. Replace that with something like, say, "resizing windows", or
"moving windows around the screen".
>> 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.
And that's probably a large part of the disconnect between our positions.
I started using E16 originally because one of my brothers was using it, and I
liked the minimalist configuration he'd set up with it (a close replica of
something he'd set up with the Win9x shell replacement Litestep). I later
trimmed it back to an even more minimalist configuration, to suit my own tastes.
I continued using it because I wanted something with certain behavior/interface
characteristics, and significant configurability in the areas I want to alter.
There are definitely more light-weight, minimalist window managers out there,
but none that I'm aware of that provide similar features in non-visual terms to
those provided by E16 - and some of those non-visual behaviors are almost more
important than the visual aspects of it all, from my perspective.
If E17 is intentionally abandoning the ability to be trimmed back as far as E16
could, then it may very well indeed not be for me.
>> 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.
Thank you for being upfront and honest about it, at least.
>> 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.
Understood. I am (and have been) aware that that has always been officially the
case.
It's just that the first Enlightenment-based UI I saw was very much minimalist,
having been already tweaked to that end by someone who preferred things that
way, and so that's my default conception of it. (I don't know exactly why he
chose it instead of a less "fancy" WM, but the effect is the same anyway.)
> 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.
And I do like a lot of the features and the corresponding customizability (of
E16, at least), that being why I haven't moved to one of the avowedly minimalist
WMs. I'm willing to make some degree of trade-off for those features and that
customizability, but only so much of one.
> 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.
I can understand and respect that position, and agree with the arguments, even
if I don't necessarily agree with the conclusions.
--
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
