Re: [e-users] Enlightenment utilizes nearly 100% of the CPU while moving windows

[Carsten H. (T. R. <ra...@ra...>]

On Sun, 12 Mar 2006 20:38:20 +0100 Martin Hauser <mh...@al...> babbled:

> Hello,
> 
> the last few days i started noticing some strange effect with
> enlightenment dr17. It started with the fact that i was not able to
> understand my peer when using skype cause the sound came in only in
> disassembled parts. It felt sort of strange and after spending hours
> investigating and having several other problems causing me to reinstall
> the system from scratch (there were some layout-issues i wanted to deal
> with anyway). 
> 
> The Problem sadly did not walk away. But it changed. Now after being
> back with a fresh install, skype was the first thing i tried. It worked
> like a charm. Then i kicked in my webbrowser and tried to move it to a
> certain position and then the fun started... it came to the fact that i
> couldn't have firefox open while skyping without skype loosing _a lot_
> of quality. Now this bothered me and i started investigating it further.
> After a while i found out, that if i put top or htop into a xterm and
> start moving it around in an otherwise blank enlightenment, the cpu
> will increase from 0 to 40 up to nearly 100% utilisation, used by
> enlightenment. If i move the xterm in front of firefox for example,
> firefox will use the 100% of the cpu not enlightenment. I think this is
> a bug but i'm not sure whether it is an enlightenment issue. But i was
> using enlightenment dr17 on the same system for about half a year,
> including frequent usage of skype and it did NEVER show this problem
> before. I maybe should add that i don't think the problem with window
> moveing existed before the reinstall.

this is a skype/kernel scheduling issues. funny that - u are moving a window and causing stuff that window is moving on top of to REDRAW. (e redraws the shadows around the window on the desktop canvas when u move) and of course this consumes cpu - the larger the window, the more than needs redrawing and thus the more cpu needed. it's no bug - it's doing what u have asked it to. and the same with firefox. u keep exposing new bits of the ffox window - it is redrawing. 100% cpu use is a sign that basically the program is working at maximum capacity on the machine you have to keep up with the work it has to do. you might want to try using renice or nice to specify process priorities (eg logwer priority of ffox, e etc. - or raise the pri of skype)

> To make sure it's not some .deb i missed to copy over from the last
> build, i did a complete rebuild and removed my ~/.e directory, just to
> be sure. But the problem wouldn't go away. It was still reproduceable.
> So i spent some more time investigating it. I first investigated that
> it's not the x-server by coping back my old xorg.conf . Nothing
> changed. Next thing i thought about was verifying the installed x
> libraries... again no change. Then i stumbled across the enlightenment
> dropshadow module. Disableing it brought only slight relief for the
> cpu. I also made sure that the X-server has not loaded any composite
> stuff or the like. 
> 
> Okay then, i switched over to another wm (fluxbox) and tried everything
> from there. The cpu utilisation there was a LOT smaller. It even is
> smaller on something bloated, like gnome. That's why i'm addressing
> enlightenment-users mailinglist and not some general mailing list. I
> spent some hours googling also but still did not find any solution to
> this.
> 
> The specs of my system would be:
> 
> Intel Pentium M 1.4 GHZ
> 256 mb ram
> in an Thinkpad r40 running debian sid/unstable

totally weird. that's not a slow machine.

> I have no idea how to actually prove it's an enlightenment bug and if 
> i should be wrong, sorry for the bother.

here is what you should do: compile all of EFL (evas, edje, ecore, eet, embryo) ANd e17 with gdb debugging then get oprofile working - and record a profile trace of e just moving a simple xterm window. you should get something like:


CPU: P4 / Xeon with 2 hyper-threads, speed 3392.59 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000
samples  %        image name               app name                 symbol name
52284    13.9321  libevas.so.1.0.0         enlightenment            evas_common_scale_rgba_in_to_out_clip_smooth_mmx
20940     5.5799  libevas.so.1.0.0         enlightenment            evas_common_blend_pixels_rgba_to_rgb_mmx
20197     5.3819  Xorg                     Xorg                     (no symbols)
19430     5.1775  libevas.so.1.0.0         enlightenment            evas_common_copy_pixels_rgba_to_rgba_sse
13456     3.5856  vmlinux                  enlightenment            __copy_from_user_ll
13098     3.4902  libevas.so.1.0.0         enlightenment            evas_common_blend_pixels_mul_color_rgba_to_rgb_mmx
9784      2.6071  nvidia_drv.so            Xorg                     _nv000794X
6568      1.7502  nvidia                   nvidia                   (no symbols)
6492      1.7299  vmlinux                  Xorg                     __copy_to_user_ll
6433      1.7142  libevas.so.1.0.0         enlightenment            evas_common_tilebuf_del_redraw
6150      1.6388  libevas.so.1.0.0         enlightenment            evas_common_tilebuf_get_render_rects
5783      1.5410  libevas.so.1.0.0         enlightenment            evas_object_clip_recalc
5254      1.4000  libX11.so.6.2            enlightenment            (no symbols)

This is the default theme, default bg etc. notice almost ALL the cpu is in rendering/drawing. its is perfectly typical as while u move evas is 1. redrawing the changes int he dropshadow (yes it's smart and not redrawing the whole window area - trust me), and redrawing the little box that shows the window co-ordinates as well.when redrawing the shadow this will also possibly mean needing to ALSO dynamically scale any bg u have. if u are using a theme with shaped (non-square) window borders this expense goes up as it is more complex. if your bg is a huge image (1600x1200 or bigger) scaled down to 1024x768 - this is done dynamically on the fly as things redraw. scaling as u go removes the need for keeping copies in memory of scaled versions of images - thus saving ram, BUT it costs cpu. it's a tradeoff.

if you don't get a profile like this - then something is weird.

> If i can provide any additional information for backtracing the
> problem, let me know how and i'll what i can do.
> 
> Thanks in advanc3e
> 
> Martin
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多
Tokyo, Japan (東京 日本)