[sugar] composite memory usage [was Re: frame auto-visibility configuration]

[Tomeu Vizoso]

On Wed, Sep 24, 2008 at 8:56 PM, Erik Garrison <erik at laptop.org> wrote:
> On Wed, Sep 24, 2008 at 07:51:30PM +0200, Tomeu Vizoso wrote:
>> On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva <hoboprimate at gmail.com> wrote:
>> > Wow, just tried Erik's instructions for using xcompmgr, and it's
>> > amazing how swift the frame slides, and how I don't see any screen
>> > redraws. The experience is totally more fluid. Does it degrade overall
>> > performance? If not much, and if that performance degradation could be
>> > recovered in another area in Sugar (general performanfe improvements),
>> > I'd vote for this to exist in joyride and even part of future stable
>> > builds.
>>
>> AFAIK, the only tradeback (and the reason why it hasn't been activated
>> yet) is that we must pay composition with increased memory usage.
>> Composition basically saves us unnecessary redraws by keeping in
>> memory copies of the windows contents.
>>
>> Martin Dengler did back in March an excellent job quantifying this tradeback:
>>
>> http://lists.laptop.org/pipermail/sugar/2008-March/004718.html
>
> Using similar methods (ps_mem.py), I get roughly the same results.
>
> I run ps_mem.py at five places, before and after enabling composite with
> 0 to 4 activites running (Chat, Paint, Write, and Browse).  (I get ten
> files named {before,after}_*_activity, and then grep them to make
> comparitive claims.)
>
>
> We can see that Activities use about the same amount of memory before
> and after the change:
>
>
> e.g. Paint:
>
> before_1_activity:  9.3 MiB +   4.2 MiB =  13.5 MiB     Paint <65be2c3b
> before_2_activity:  9.2 MiB +   3.1 MiB =  12.3 MiB     Paint <65be2c3b
> before_3_activity:  9.4 MiB +   2.5 MiB =  11.9 MiB     Paint <65be2c3b
> before_4_activity:  9.4 MiB +   2.1 MiB =  11.5 MiB     Paint <65be2c3b
>
> after_1_activity:  9.3 MiB +   4.2 MiB =  13.5 MiB      Paint <eb84d7a4
> after_2_activity:  9.3 MiB +   3.1 MiB =  12.4 MiB      Paint <eb84d7a4
> after_3_activity:  9.2 MiB +   2.5 MiB =  11.7 MiB      Paint <eb84d7a4
> after_4_activity:  9.2 MiB +   2.1 MiB =  11.3 MiB      Paint <eb84d7a4
>
>
> e.g. Write:
>
> before_3_activity: 19.4 MiB +   2.8 MiB =  22.2 MiB     Write <d2756bab
> before_4_activity: 19.4 MiB +   2.4 MiB =  21.8 MiB     Write <d2756bab
>
> after_3_activity: 19.4 MiB +   2.8 MiB =  22.2 MiB      Write <d863e164
> after_4_activity: 19.4 MiB +   2.4 MiB =  21.8 MiB      Write <d863e164
>
>
> However, there is an obvious memory difference between the two
> situations:
>
>                                 [ total memory usage ]
>
> before_0_activity-                         86.4 MiB
> before_1_activity-                         98.0 MiB
> before_2_activity-                        126.6 MiB
> before_3_activity-                        146.2 MiB
> before_4_activity-                        154.9 MiB
>
> after_0_activity-                         88.5 MiB
> after_1_activity-                        109.8 MiB
> after_2_activity-                        138.0 MiB
> after_3_activity-                        162.7 MiB
> after_4_activity-                        173.2 MiB
>
> When composition is enabled, we used 18.3 MiB more to run the same 4
> activities.
>
>
> Following Martin Dengler's lead, we discover that this memory is mostly
> used by the X server:
>
> bash-3.2# grep Xorg before*
> before_0_activity:  3.1 MiB + 390.5 KiB =   3.5 MiB     Xorg
> before_1_activity:  3.2 MiB + 430.0 KiB =   3.6 MiB     Xorg
> before_2_activity:  3.4 MiB + 420.0 KiB =   3.9 MiB     Xorg
> before_3_activity:  3.7 MiB + 509.5 KiB =   4.2 MiB     Xorg
> before_4_activity:  3.7 MiB + 507.5 KiB =   4.2 MiB     Xorg
>
> bash-3.2# grep Xorg after*
> after_0_activity:  3.0 MiB + 342.5 KiB =   3.3 MiB      Xorg
> after_1_activity: 10.9 MiB + 445.0 KiB =  11.4 MiB      Xorg
> after_2_activity: 13.1 MiB + 425.5 KiB =  13.5 MiB      Xorg
> after_3_activity: 18.0 MiB + 506.0 KiB =  18.5 MiB      Xorg
> after_4_activity: 19.9 MiB + 504.0 KiB =  20.4 MiB      Xorg
>
> A little under 15 MiB of increase.
>
>>
>> I'd vote for activating composition ASAP once we have a 9.1 joyride
>> branch and see how we can find the sweetest spot between speed and
>> memory usage.
>>
>
> I agree.
>
> There also may be bugs which we need to shake out.  If this is a feature
> we know we want for 9.1, the sooner we start testing the better.

Bernie has talked about some wm hints that can be set on windows so
they get unredirected and thus their offscreen pixmaps released. Not
sure if matchbox would support them, though.

Related with all this is the decision to switch window managers.

Perhaps keeping redirected just the two activities on top of the stack
plus the desktop window may be enough? I think that would mean a
constant 12MB, approx.

Regards,

Tomeu