Mini-Conference Proposal: sugar performance

[Gary C Martin]

On 23 Mar 2008, at 18:32, Tomeu Vizoso wrote:

> The idea is that, instead of waiting 5 seconds for the full UI to
> appear, the activity window would appear after, say, 3 seconds, half a
> second later the document will get loaded, and half a second later the
> user will be able to share the activity or invite somebody.
>
> Can your activities do something about this?

I have just one activity at the moment, Moon, the difficulty I'd face  
is that I really don't want multiple redraws at start-up for what  
you're calling the document area, it's quite cpu expensive in my case  
(at least a second or so per refresh). And I have a planned activity  
where it may be even worse (a lon/lat tag sharable 3D Earth view).

Currently there is no way an activity can know (in its __init__) if  
read_file() is going to be called, so with your proposed changes, yes  
I can (and do) set-up the default tool bar, a black screen and my text  
panel early, but I'd then need to have my __init__ set-up a timer to  
arbitrarily ~0.5 or more sec, just incase a read_file() call arrives.  
So every fresh launch will twiddle it's fingers for an extra  
unnecessary ~0.5 sec, and if after a Journal launch and the ~0.5 sec  
was not long enough, the user will get a nasty double redraw of the  
main cpu expensive widget refresh, slowing things down even more (and  
looking bad as well).

Letting the activity know data is, or isn't, expected from the Journal  
is the missing feature here. Always having a read_file() xor a  
clean_start() call would resolve this. Other options could be to just  
always call read_file() data or no data and let the activity deal with  
perhaps a file_name = None, but that will likely break some existing  
activities.

Regards,
Gary

P.S. clean_start() is just a stand-in name, sure you'd have a better  
name for it, maybe no_file()? On OS X under Cocoa we have the usual  
init method to get the base things going, and then later an  
awakeFromNib method is called so that an application knows its  
resource files have been dealt with by the runtime – that's when we  
can start parsing preference settings etc and tweaking the UI to  
match. There's even then a final applicationDidFinishLaunching method  
you override to kick things off once the set-up is all over.