9.1 Proposal: Top five performance problems

[Erik Garrison]

On Fri, Oct 24, 2008 at 01:56:47AM +0200, Marco Pesenti Gritti wrote:
> Problems and ideas in no particular order.
> 
> * Sugar shell startup is too slow.
> 
> Reduce dependencies, single process shell, modularize and delay
> initialization of components which are not immediately necessary,
> measure constantly to avoid regressions and monitor progress.
> 
> * Icons rendering is slow and uses too much memory.
> 
> Cache svg icon on disk pre-rendered and mmap them, render colored
> icons using a mask per color, user server side pixmaps to speed up
> rendering of some of the icons.
> 

What about changing the kind of visual feedback we give.  Instead of
pulsing icons what about icons with a string of dots beneath, a progress
bar, flashing, or another kind of overlay feedback which requires fewer
visual changes (frames) and/or could be overlaid on top of existing
icons without calculating a new animation for every icon?

Just thoughts.

> * The frame is too slow to appear and disappear.
> 
> Experiment with pixmap caching. Is an empty frame fast enough?
> Composite the active window and the frame.

What about just turning on X Composite for everything?  From the user's
perspective this wholly resolves a lot of issues associated with
rendering performance.  From a programmer-resources perspective it's
also quite straightforward.

The problem is that we have fallout in terms of memory allocation, at a
cost of about 2mb per activity window.  That said, switching between
activities is *instantaneous*.  More problematically I see no clever
algorithm to figure out where a user is going to go in the activity
stack next, which might help us choose which windows to unmap.

Could we discuss this during the talk?

Erik