Version: (using KDE KDE 3.4.1) Installed from: Unlisted Binary Package A Picture says 1000 words. Please see attachment: screen.capture_-_2004.10.28_-_Xcompmgr_-_Playing.Around.With.Shadows.avi
Created attachment 11471 [details] screen.capture_-_2004.10.28_-_Xcompmgr_-_Playing.Around.With.Shadows.avi
btw, if one is interested, I've uploaded the 'source' behind this Vid' to: http://www.slicker.org/dev/danalien/playground/screen.capture_-_2004.10.28_-_Xcompmgr_-_Playing.Around.With.Shadows.avi.-.source.tar.bz2
Hi, Awhile ago, I played around with Xcompmgr ... and one thing led to the other [0] ... The basic/simple idéa was to use 'shadows' to illustrate depth, with (subtly) dynamic-shadows *of sorts*. That ${Things} closer to the 'desktop/background/wallpaper' have less, and vise versa with those things that are farther away, more shadow. Cheers. --- see also: http://mail.kde.org/pipermail/panel-devel/2005-June/000179.html
uummh, yeah. *crank-it* I forgot to imply: mplayer -loop 0 ${file} ... and let it loop around awhile, while ${you} ogle at it :-)
this'd be easy to implement - i just worry how CPU consuming it will be (changing the window shadow implies an internal recreation/repaint of the whole window) and how irritating the flicker on the screen will be i've yet not seen the video, but you may describe your personal experiences and maybe top output on doing this on e.g. 10 windows on the other hand i'm quite satisfied with two shadow sizes (front/back) as from a certain window amount the changes will become *very* subtile and the front window should imho have a much bigger and lighter shadow than the rest
Thomas, >CPU consuming yeah, I know what you mean. but, I'll share something with you, I didn't envision this of being implemented in the current "CPU draws the graphics" scenario, but in the world where it's all shoved down the GPU's throat :-) >i've yet not seen the video, plz, do - I won't be buggered to scribble 1000 words :-) >but you may describe your personal experiences and >maybe top output on doing this on e.g. 10 windows *sorry?* my decoding-chipher melted :-) /* I got the 1st line, but the 2nd?... */ >and the front window should imho have a much bigger >and lighter shadow than the rest dynamic-soft-shadow--stuff? *right?* ... I think, I did that too? :), to fiddle with the 'intensity' of the shadow somehow. Here's the values I used: 10_-_xcompmgr -cCfF -l -5 -t -5 -r 5.png 11_-_xcompmgr -cCfF -l -10 -t -10 -r 10.png 12_-_xcompmgr -cCfF -l -15 -t -15 -r 15.png 13_-_xcompmgr -cCfF -l -20 -t -20 -r 20.png 14_-_xcompmgr -cCfF -l -25 -t -25 -r 25.png 15_-_xcompmgr -cCfF -l -30 -t -30 -r 30.png 16_-_xcompmgr -cCfF -l -35 -t -35 -r 35.png 17_-_xcompmgr -cCfF -l -40 -t -40 -r 40.png 18_-_xcompmgr -cCfF -l -45 -t -45 -r 45.png 19_-_xcompmgr -cCfF -l -50 -t -50 -r 50.png 20_-_xcompmgr -cCfF -l -55 -t -55 -r 55.png 22_-_xcompmgr -cCfF -l -45 -t -45 -r 45.png 23_-_xcompmgr -cCfF -l -40 -t -40 -r 40.png 24_-_xcompmgr -cCfF -l -35 -t -35 -r 35.png 25_-_xcompmgr -cCfF -l -30 -t -30 -r 30.png 26_-_xcompmgr -cCfF -l -25 -t -25 -r 25.png 27_-_xcompmgr -cCfF -l -20 -t -20 -r 20.png 28_-_xcompmgr -cCfF -l -15 -t -15 -r 15.png 29_-_xcompmgr -cCfF -l -10 -t -10 -r 10.png
> but in the world where it's all shoved down the GPU's throat :-) having GPU power on side would of course be cool, but currently the composite design is far away from Quartz eXtreme - mainly due to the closed source Xserver problem and even not nVidia provides full Render support (while ati afaik still doesn't at all). So the process allways runs through the CPU/cache what e.g. dramatically breaks down if the handled Pixmap overflows the cache (try e.g. 1600x1200x32 on 512kb) >maybe top output on doing this on e.g. 10 windows type top into a shell, you'll see your running processes and some info, type top -p $(pidof X) and you'll see process behaviour of X, so you can see cpu/mem usage (type man:top into konqui to get much more info ;) >dynamic-soft-shadow--stuff? *right?* yeah, i hacked that times ago onto xcompmgr - kompmgr of course supports it as well (it's based on my hacks on xcompmgr) - if this is all you're requesting, we can close this bug ;)
>mainly due to the closed source Xserver problem ??? - Xorg or XFree86? ... or both? .... and I thought both where fully F/OSS... or you're just refering to that some gfx_drivers are closed-source? ... >and even not nVidia provides full Render support.. figured so much. why I'm more looking at XGI (www.xgitech.com).... even managed to order two V3's from my local supplier :-) but, say - would you mind 'hacking' on making some ubergood XGI drivers for Xorg? ...to lator hack on a *real* 'Quartz eXtreme'-solution for F/OSS?.... if so, when *those puppies arrive, I could send one board to you =) >type top into a shell ... no need, I can tell you, my machine started to chuckle as the shadow grew :-) >if this is all you're requesting. No, I'm requesting: "use more/less shadows to illustrate depth" but, sure, if one would get "dynamic-soft-shadow--stuff" for the price of one, fine by me =)
> ??? - Xorg or XFree86? ... or both? .... and I thought both where fully F/OSS... yes they are, (though Xorg came up because XFree was not so much open ;) but the Xserver itself is the "Graphics driver" somehow and though there are open variants, they are hardly usefull for this purpose (at least not nVidia) > but, say - would you mind 'hacking' on making some ubergood XGI drivers for Xorg? hardly, i'm not that experienced on X and on top of this, a complete redesign of several X extensions would be necessary. Also there are various things in development - check the X mailing list on this (they depend on GL or render and use various designs - it's a mess... ;) >No, I'm requesting: "use more/less shadows to illustrate depth" the problem on this would be visability - sa you want 4px shadows at least and 16 pix shadows at max and active windows shadows twice as big as max inactive. so you have 4px left to illustrate the difference - you hardly will notice anything - having soft wide shadows for active and dense tight shadows for inactive windows is afaik enough - if things would run faster i'd rather modify the windows opacity (so front window is opaque and the rest fades away to 10%)
>it's a mess... ;) as all things tend to be :-) >the problem on this would be visability [...] ...well, I'd like not to speculate. But, the idea is to be subtle, e.g. the user shouldn't consciously notice *this_effect_I_am_requesting - and just be there for their unconscious minds to grasp :-) >if things would run faster i'd rather modify the windows opacity >(so front window is opaque and the rest fades away to 10%) well, that's an entirely different effect - and I say why not to *that too, but why not to *this too? ... and have options to let users enable/disable what ever they choose :-) /me for letting people choose...
*** This bug has been confirmed by popular vote. ***
Setting as duplicate of the newer bug as we don't have kompmgr anymore. *** This bug has been marked as a duplicate of bug 247462 ***