On Mon, 30 Jul 2012 08:46:04 -0400 The Wanderer <wande...@fastmail.fm> said:
> On 07/29/2012 10:41 PM, Carsten Haitzler (The Rasterman) wrote:
>
> > On Sun, 29 Jul 2012 20:57:03 -0400 The Wanderer <wande...@fastmail.fm> 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.
actually even in e16 - it's always there. the root window is always there.
desktops 1, 2, 3 also have their own desktop windows. that window is always
there - with its wallpaper. the wallpaper HAPPENS to be a single color - but
its all there. :) e17 is the same.
> 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.
i do - as it consumes the same resources and is rendered etc. the same way. it
works via the same pipeline. a 1x1 pixel image and a solid color are almost
equivalent in footprint.
> 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.
edje does - via rectangles in edj files. i just don't see the point of making a
gui for you to do it as its such a rare case when selecting the single color
image ends up about the same. all u dont have is a gui dialog to go generate
that edj file for u. thats all - the feature is there in e17 if uw ant to make
your own edj file (and for a solid color thats trivial:
echo 'collections { group { name: "e/desktop/background"; parts { part { name:
"bg"; description { state: "default" 0.0; type: RECT; color: 0 0 0
255; } } } } }' > _t.edc; edje_cc _t.edc ~/.e/e/backgrounds/solid-black.edj; rm
_t.edc
replace 0 0 0 with whatever RGR color u like. replace solid-black with whatever
named file u'd like. create dozens of them. all possible in e17.
> >> 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".
yup - it consumes more. that's what eyecandy costs. :)
> >> 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.
e16 never was minimalist... it was actually well known for being rather heavy.
i think you confuse minimalist in terms of resource and minimalist in terms of
LOOK. you want minimalist LOOKS, and maybe you equate a miniamlist look with
being minimalist in resources (which very often is far from the truth). :)
> 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.
e17 provides almost everything e16 provides and then a mountain more in
addition. e17 compared to e16 in features is like 100:1. it has so many more,
it's not funny. not all of them you may have discovered or know how to tweak or
access. a lot of them are buried inside doing themes (edje files). but it is a
feature and these edje files provide more than only skin - they provide some
level of functionality and layout too, spacing and animation and more.
> 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.
it's aims are irrelevant to what e16 does. never has there been something like
"well for e17 we want to just drop all the trim-back features". e17 is entirely
a project on its own devoid of e16. it just comes from the same developers. if
you are so concerned that e17 is "too heavy" for you then you probably have a
machine that is so ancient that i'm surprised it hasn't died from living under
the mountain of dust it's under. seriously - e17 is running on PHONES. it's
been running on them for years now. if it can run well on a phone... you're
good to go. your argument of "its not minimal enough to work on my box", *IF*
that is your argument, imho is an invalid one, as it works just fine and leaves
plenty of room to spare for apps. but if you wish to make that argument, in the
age of machines with gigabytes of ram (even phones are hitting that now), etc.
then... well... e is not for you. you belong in a specialised minimalist niche.
use twm or fvwm - they will be incredibly minimal and suit you nicely. if that
is your thing. e17 is not that. e17 is for people who want and like eyecandy.
they appreciate flexibility and would like to not pay overly much for it, but
will pay still.
just remember - my x86 test machine is a penitum-m @ 600mhz, 512m ram, 1024x768
and ZERO opengl acceleration. all done on software and e17 works a charm on
that. sure - not silky smooth - but smooth enough and acceptable and it LOOKS
nice. the 20g hdd on that thing is ancient (1.8" drive) and its SLOW as all
hell. linear reads only pull in at 18m/sec (modern hdd's pull in bout
80-120mb/sec). seek times on that are attrocious. just listing files with find
takes about 2.5x as long as a modern hdd (this is very seek intensive).
anyway - this box runs e17 fine. even with a hefty base ubuntu install. with
compositing (software) on etc. too. add this to the fact that a lot of
development on e and efl is focused on embedded and mobile, things tend to stay
lean. we can be leaner, but then we drop lots of features/capabilities and we
don't want to do that.
> >> 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.)
well u can always tweak e17 to be more "minimalist looking" and u'll "feel
better about it" :) but it may not actually save u much ram/cpu :)
> > 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.
sure. and e17 makes that tradeoff too. our of the box its probably not as
minimalist as u'd like it to LOOK, but that is actually the intent and plan. :)
> > 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
> 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
------------------------------------------------------------------------------
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
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
