On Thu, 08 Dec 2011 13:07:34 +0200 Robert Krambovitis <rob...@split.gr> said:
> Ok, so clearing .cache -> no effect
>
> Fresh installation of old opensuse -> Fine
> Dist-upgrade above -> Still fine !!
>
> Fresh install of new opensuse -> No OpenGL !!
> This is using the same kernel, driver, enlightenment rpms as above.
well there is something that is different between a freshly installed opensusue
and an old opensusue gone through a dist-upgrade. hwew is what i'd do. i'd list
every file on the system (except /var/log, /sys, /proc and /home and /opt -
which is where i assume the only thing installed is e17+efl) and see what is
different:
for I in `find /var -print | sort`; do echo -n "$I "; stat $I | grep size |
grep -v blksize | awk '{printf("%s\n", $2);}'; done > /tmp/flog
take the 2 flog files and then put them through diff. of course some files will
be expected to be different - like packaging db's probably, but somewhere in
this list of files that are different is possibly our cause.
> I can only assume that there is something missing from the system.
> What could that possibly be ?
see above :)
> On a side note, I noticed than when the compositor is enabled, even when
> idle, strace shows plenty of activity, whereas without the compositor
you sun strace in a terminal inside your x session? you do knwo that every
redraw of of the terminal means e wakes up to re-composite the screen.. which
leads to more strace output.. which leadds to a re-composite.. which leads to
more strace output... :) you can't monitor a compositor from within itself -
it's a self-feeding loop. ssh in from a remote host or do it from a text
console (and log to a file). you'll find e only is waking up and doing things
when it needs to - ie to poll on cpufreq or temperature or to handle a redraw
by a client (that blinking cursor in your xterm will cause e to wake up every
time it blinks on or off and handle as redraw - as will any changes to cpufreq
dials or the clock gadget etc.)
> enabled, strace shows idle enlightenment when not doing anything.
> I believe that the comp module is due some tlc, as even on the "working"
> systems performance is sub-par.
not really. i think you're just doing it wrong. :) see above. e sleeps for
several seconds at a time in between it having "things to do" when it wakes up
and does them. the ONLY thing that might be able to be improved is reducing
redraw areas when using opengl. as such, evas, when it redraws with gl, redraws
the whole canvas, not just the update region. this is necessary since it uses
swapbuffers. you cannot do swapbuffers and NOT redraw everything. swapping
buffers means the driver can optimize a swap of a full screen buffer to be
literally a swap - tat means it just swaps "links" where fb now points to what
was the back buffer, and what was the frontbuffer nos is the backbuffer. the
swap itself equates to the cost of changing a pointer (effectively). if your
driver is not so good - it'll still COPY from back to front buffer anyway. also
swaps mean you can nicely and seamlessly do tear-free vsynced rendering (copies
have no guarantee that the copy can be done faster than the screen refresh).
where evas could do better is if small regions are updated, it could just
redraw that and copy from back to front (glcopypixels) where the cost of the
copy is less that the cost of the excess over-draw. the problem here is that in
the past i have found copypixels often not accelerated. that means the CPU
reads from video mem and writes to other video mem. this can be abhorrently
slow. if you look in evas's gl_x11 engine u'll even find commented out code to
do just this. i've found it either to not work or be slow. anyway - that's the
only thing i know of that can be improved. yes - evas adds overhead for scene
graph management and other fun things, but not much. if you look at compiz vs
e17, e17 uses about 20% more cpu (compiz uses about 10%, e17 about 12% cpu)
when we are doing full screen redraws (eg video player playing full screen).
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> 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
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
