On Sun, 26 Feb 2012 23:18:48 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Sun, 26 Feb 2012 21:40:26 +1000 David Seikel <onef...@gmail.com> > said: > > > On Sun, 26 Feb 2012 10:33:47 +0900 Carsten Haitzler (The Rasterman) > > <ras...@rasterman.com> wrote: > > > > > On Sun, 26 Feb 2012 09:39:04 +1000 David Seikel > > > <onef...@gmail.com> said: > > > > > > > On Sat, 25 Feb 2012 18:33:09 +0000 Mick > > > > <michaelkintz...@gmail.com> wrote: > > > > > > > > > On Friday 24 Feb 2012 10:28:22 you wrote: > > > > > > On Fri, 24 Feb 2012 09:05:25 +0000 Mick > > > > > > <michaelkintz...@gmail.com> said: > > > > > > > On Friday 24 Feb 2012 01:05:15 Carsten Haitzler wrote: > > > > > > > > On Fri, 24 Feb 2012 00:57:58 +0000 Mick > > > > > > > > <michaelkintz...@gmail.com> > > > > > said: > > > > > > > > > On Friday 24 Feb 2012 00:21:00 Carsten Haitzler wrote: > > > > > > > > > > you just need xproto + xlibs. > > > > > > > > > > > > > > > > > > > > just remember that compositing will be broken for > > > > > > > > > > you due to your server being old anyway, but e/efl > > > > > > > > > > will compile and run but compositing may fail (and > > > > > > > > > > we will be moving to compositing only in future). > > > > > > > > > > > > > > > > > > Oops! Won't we have an option to switch it off if we > > > > > > > > > want to? > > > > > > > > > > > > > > > > in future - no. for e17 release it'll stay a module, but > > > > > > > > after that it'll be compositing only. get used to it - i > > > > > > > > suggest u use it and report bugs/issues. :) > > > > > > > > > > > > > > Well, I can't say it is bug(s) but it is a matter of > > > > > > > overall responsiveness and resources used, especially on > > > > > > > older systems. Composite uses (slightly) more CPU and > > > > > > > memory on my amd64 box and more so on an old x86 with a > > > > > > > PIII on it. > > > > > > > > > > > > the lowest-end machine i've use it on is a pentium-m@600mhz > > > > > > - it works very well there. sure - not silky smooth but very > > > > > > usable... considering its copying mountains of data around > > > > > > and rendering everything with the cpu (clients included) > > > > > > it's pretty amazing. :) seriously... software compositing > > > > > > is working (decently) on PHONES... yes - its a price to pay > > > > > > - software compositing adds an extra copy from x to local > > > > > > data first before drawing and then writing it back to x - > > > > > > so it adds extra overhead. theres no zero copy path like gl > > > > > > + texture-from-pixmap. > > > > > > > > > > > > > Plus when say I watch something in mplayer and I move > > > > > > > focus to another window, then the mplayer window becomes > > > > > > > transparent and the picture fades. Since the cursor does > > > > > > > not automatically follow my eyes I just switch composite > > > > > > > off. > > > > > > > > > > > > you can select what style u want with compositing - its > > > > > > there in the comp gui to select. you can have the fading > > > > > > disabled - wobbles too etc. > > > > > > > > > > Hmmm ... my PIII comes up with this compositor warning: > > > > > > > > > > "Your screen does not support OpenGL. Falling back to > > > > > software engine" > > > > > > > > > > It seems it doesn't like the Radeon Mobility M6 LY that this > > > > > old laptop is running. I don't recall having this problem > > > > > before. I should try a later snapshot to see if it persists. > > > > > > > > > > I can see in top enlightenment runs between 3.4 - 5% of the > > > > > CPU with bursts up to 35.9 - 54% when I move between windows > > > > > (a couple of aterms and a xterm). > > > > > > > > > > Without composite enlightenment shows between 0.5 - 2.5% of > > > > > the CPU with bursts up to 7.9% when I move between windows. > > > > > > > > > > So, yes it is usable, but if I am doing something heavy on > > > > > this little box like compiling, compressing files, etc, then > > > > > it slows down noticeably and this is why I would rather give > > > > > up compositing effects for functionality. > > > > > > > > > > Are there some settings in the composite configuration, which > > > > > will minimise the load? > > > > > > > > I'm seeing 30 to 50% of one core being used with the composite > > > > module turned on, even worse in software mode, and that was > > > > with it sitting idle. It did indeed interfere with my 3D app, > > > > it stuttered. I jiggled the settings somewhat, but did not get > > > > much better than that. > > > > > > it's not idle. something is re-rendering continually. are you on > > > up-to-date efl? > > > > "Idle" in this case means running "top -c" on a borderless, > > focused, and fully maximised terminal, with the "still" composite > > style, then just watching it for a while. So in this case, the > > composite does not have much to do, as anything running under the > > window should be irrelevant? In case it matters, I do run the > > clock, tclock, and cpufreq modules, as well as gkrellm, nothing > > else is updating. > > modules re-rendering animation (eg cpufreq changing its needle), and > in fact many things u dont think redraw at all but do (they just > re-draw the same thing over and over) may cause it. > > > > > CPU: AMD Phenom(tm) II X4 840 Processor > > > > Memory: 3961 MB > > > > Graphics Card: GeForce GT 220/PCI/SSE2 > > > > OpenGL Version: 3.2.0 NVIDIA 195.36.24 > > > > > > > > Unloaded the module again. > > > > > > you enabled opengl AND texture-from-pixmap? i've had e comp > > > working silky smooth on a gf6600 with 3520x1200 of pixels. games > > > pay the price of another buffer copy - that's it. nb i did add > > > some options for nvidia's driver: > > > > > > Option "TripleBuffer" "True" > > > Option "Coolbits" "7" > > > Option "UseEvents" "True" > > > Option "OnDemandVBlankInterrupts" "True" > > > > Yes, openGL and texture from pixmap are both enabled. I have > > updated e17 just now, added those nVidia driver options, and tested > > again. > > > > The 3D virtual world viewer now runs smoothly again, and I'd have > > to do some careful tests to see if there is any difference in frame > > rate - in other words, no noticeable difference. Which means not > > enough difference for me to worry. I'm not a frame rate whore. lol > > > > In the "idle" test as mentioned above, it's now using 20 to 40% of > > one core, so that's better. Also, using twice as much ram as it > > was before. > > > > Ah, closing gkrellm drops composite E17's CPU usage to mostly 2% of > > one core, with peaks of up to 25%. So it DOES matter what's running > > under a non transparent window. I have the gkrellm stretched out to > > it's maximum size, which takes up about half the screen real estate. > > correct. and if your gkrellm uses a shaped window it'll be much much > mores as for shaped windows e has to go back to pixel grabbing > because it has to implement a shape mask by modifying the alpha pixel > values of an image... i just suggest not using anything that makes > shaped windows. I'll double check gkrellm using shaped windows. > > > wait a sec.. your nvidia drivers are ANCIENT... like from when > > > dinosaurs roamed the earth! get an update man! > > > > I run mostly stock current Ubuntu LTS for good reasons, and I wont > > update until some time after their next Long Term Stable release is > > out. And just in case people had not figured it out (surprising the > > number of people that get this wrong, but that should know better) > > the current Ubuntu LTS is 10.04, almost two years old, NOT 11.04. > > yes - but whatever ubuntu does, nvidia has its own bugfix/maintenance > system and ubuntu doesnt update the nvidia driver at all, so you get > zero bugfixes over your lts period with your nvidia driver. nvidia > fixed several bugs in their driver, one was a resource leak that > happens after enough e restarts, or well they mitigated it and > another was a polling./spinning glxwaitgl - i reported that and they > were meant to have fixed it in a latest release. > > > So the graphics driver I use is the standard Ubuntu LTS one, and I > > will not update it, unless Ubuntu push out an update. That's one > > of the things that's very important to me to keep stock LTS. I do > > run some bleeding edge stuff, like E17 for instance, but those > > things don't impact on my reasons for needing to use current Ubuntu > > LTS. > > well, up to you - but then you will have to live with some of these > bugs that frankly do at times make e totally unusable with > compositing on. > > > Not sure if those nVidia driver options will stay, so I might test > > without them later. They go against the "keep it stock LTS dammit" > > grain. lol > > lts makes no real effort to improve your options, so just assuming > "everything must always be stock" is going to put you in trouble > often enough. keep things stock that u dont need to alter, but some > you do. One of the major points of me sticking with stock Ubuntu LTS is to support people that use it. I did a survey of the people that use software I write or maintain. Stock Ubuntu 10.04 is the base line for what I support. So if someone is having an obscure bug, I can say "works for me on stock Ubuntu LTS, what's different with you?". Instead of saying "Um, go through this painful manual method of updating your graphics drivers that also includes scary kernel module update thingy, coz Ubuntu don't provide a nice easy GUI for non tech users like you.". Normal users use old crap. As a developer, I gotta live with that, but I still get to draw the line, and I draw it at a very reasonable Long Term Stable release of a very popular Linux distro. So for the stuff involved in the code I write, I keep it stock and stable. I generally keep EFL more or less up to date, but for my embedded work I write to whatever is the latest stable EFL release, then test it under qemu and real hardware using the latest stable EFL. For my virtual world work, I need it to work on the drivers Ubuntu supply, and the default options Ubuntu provide. Coz chances are, any random user has exactly that, and getting them to change is too hard and scary for them. > > I'll do some more tests, but I think I can mostly live with it now, > > with the promise of better performance to come in E18. The virtual > > world stuff is of major importance, so anything impacting it's > > performance is a no no. I sometimes get paid to develop that stuff. > > > > Just for further info, I run six virtual desktops, on one monitor, > > at 1920x1080 24 bit. I stay well away from E17's fullscreen mode, > > think I've mentioned that enough over the years and why, using > > fully maximised > > i dont remember you mentioning it - but e17's fullscreen handler just > handles normal netwm requests from clients and it works for me for > everything that uses the netwm request. I've always bitched for years about E fullscreen not doing what I want. This is putting windows into fullscreen mode manually, not windows requesting it. Though I gave up bitching, so perhaps you forgot. And perhaps it got "fixed"? > > > borderless windows instead. For me, "fullscreen" just means it > > takes up all of the screen, NOT that I loose control and cannot > > switch to other windows. I really don't care what apps that want > > to take over control of my screen want to do, especially since most > > of those are buggy, I want complete control of my own computer. :-P > > thats how netwm fullscreen and e fullscreen work. keybindings stay. > alt+right mouse on window stays still. you can alt_tab and otherwise > switch desktops as normal. a lo9t of games that use sdl dont use this > path and go try do their own "bypass the wm" fullscreen and that just > falls apart badly like you mention above - users cant control the > window after that, desktop switching doesnt work etc. they grab > keyboard and mouse etc. realistically for fps's u need to grab the > mouse to get relative movements, though they should have a > grab/ungrab sequence like u find in vmware and xephyr, but they dont. I do 3D virtual worlds, not FPS's. Mouse and keyboard grabbing don't happen. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
