[sugar] simple hacks to improve the performance of the Sugar UI

[Erik Garrison]

On Sat, Oct 18, 2008 at 5:08 AM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> On Sat, Oct 18, 2008 at 7:35 AM, Andrés Ambrois <andresambrois at gmail.com>
> wrote:
>
> Just a couple of notes.
>
>
>>
>> [PATCH] sugar-homewindow-no-transition.patch
>>
>> This removes the usage of TransitionBox from HomeWindow.py. TransitionBox
>> is
>> used to animate the Xo Guy while moving between zoom levels.
>> This patch makes transition from activities to the home box almost
>> instantaneous and removes the annoying flickering.
>
> git master doesn't have an activity -> home animation... I need to check if
> that's what Eben actually want though :) I'm also looking into fixing the
> flickering when closing an activity today.
>
>>
>> I have tried your hacks and I must say the frame behaves a lot better with
>> compositing enabled. I haven't run any serious memory pressure tests, but
>> I
>> can have around 8-9 activities open before encountering OOM problems. No
>> idea
>> what the previous statistics were.
>
> Compositing will not make a huge difference about OOM. It's 2 mb per
> activity, so it would be something like 1.5 activities less you can run. The
> impact it's in theory going to have is to fill up VRAM and hence making
> graphics performance with a lot of activities open painful.
>

I suggest testing xcompmgr without compcache (or with small/large RAM
allocations for it).  My impression is that when using xcompmgr, but
not using compcache the upper limit in terms of number of activities
before OOM was 5 or 6.  I'm going to do a code review to better
understand what compositing is doing with the window buffers.  Also if
anyone has advice about how to find where memory is getting stored
(VRAM or RAM) please note.

We need to test memory limits programatically but unfortunately there
is a kernel bug which we're hitting in low memory situations in which
the OOM killer is never invoked, but the system grinds to a halt.
This will make automated testing of this aspect quite painful.  Until
we resolve this we can't just have the system look in the kernel
messages for OOM events to help us test the limits.

Erik